From nobody Fri Mar 3 16:25:17 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C65612706D; Fri, 3 Mar 2017 16:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 frFQV70myTzd; Fri, 3 Mar 2017 16:25:00 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 03E0B128AB0; Fri, 3 Mar 2017 16:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v240Oj9j005097; Sat, 4 Mar 2017 01:24:45 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vZmyj0KjVzDJ6h; Sat, 4 Mar 2017 01:24:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <880044A0-E3F0-436D-BB45-6751A01EDB6B@tzi.org> Date: Sat, 4 Mar 2017 01:24:44 +0100 X-Mao-Original-Outgoing-Id: 510279884.362881-152b94dac84d17b5022d5bfde5097d7b Content-Transfer-Encoding: quoted-printable Message-Id: References: <880044A0-E3F0-436D-BB45-6751A01EDB6B@tzi.org> To: ace@ietf.org, "core@ietf.org WG" , cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [COSE] Constrained Node/Network Cluster @ IETF98: FINAL AGENDA X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 00:25:02 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF98. Remember that agenda definitions are never really "FINAL"... "While this is considered the final agenda for printing, changes may be made to the agenda up until and during the meeting. Updates will be reflected on the web versions of the agenda." Compared to the draft agenda, this has mostly room changes. v6ops moved around, and tsvarea got extended to an almost four-hour meeting. All times are CDT (UTC-0500) -- yes, the US will be on DST already for a couple of weeks, while Europe moves over right on Mar 26th. (The browser timezone function still is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SUNDAY, March 26, 2017 0900-1700 IRTF*** icnrg, with some t2trg-related items on the = agenda MONDAY, March 27, 2017 0900-1130 Morning Session I Zurich A ART dispatch Dispatch WG Zurich D INT homenet Home Networking WG Zurich C SEC *** ace Authentication and Authorization for = Constrained Environments WG 1300-1500 Afternoon Session I Vevey 1/2 IRTF*** t2trg Thing-to-Thing Zurich A OPS anima Autonomic Networking Integrated Model = and Approach WG Zurich B RTG bier Bit Indexed Explicit Replication WG Zurich G RTG detnet Deterministic Networking WG Zurich E/F TSV tsvarea Transport Area Open Meeting 1520-1650 Afternoon Session II Zurich A SEC tokbind Token Binding WG Zurich E/F TSV tsvarea Transport Area Open Meeting 1710-1810 Afternoon Session III Zurich E/F GEN wugh WGs Using GitHub BOF Zurich D INT *** lwig Light-Weight Implementation Guidance WG Montreux 3 SEC curdle CURves, Deprecating and a Little more = Encryption WG Zurich C SEC oauth Web Authorization Protocol WG Vevey 1/2 TSV tsvwg Transport Area Working Group WG TUESDAY, March 28, 2017 0900-1130 Morning Session I Zurich C INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Zurich D IRTF maprg Measurement and Analysis for Protocols Zurich E/F SEC tls Transport Layer Security WG 1300-1430 Afternoon Session I Zurich C ART *** core Constrained RESTful Environments WG Zurich D INT intarea Internet Area Working Group WG Zurich A RTG babel Babel routing protocol WG 1450-1620 Afternoon Session II Zurich G ART uta Using TLS in Applications WG Zurich E/F SEC *** teep A Protocol for Dynamic Trusted Execution = Environment Enablement BOF 1640-1840 Afternoon Session III Zurich B INT dnssd Extensions for Scalable DNS Service = Discovery WG Zurich E/F TSV taps Transport Services WG WEDNESDAY, March 29, 2017 0900-1130 Morning Session I Zurich A INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG 1300-1500 Afternoon Session I Zurich C INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Zurich A OPS v6ops IPv6 Operations WG Montreux 3 TSV tcpinc TCP Increased Security WG THURSDAY, March 30, 2017 0900-1130 Morning Session I Zurich D INT 6man IPv6 Maintenance WG Zurich C IRTF icnrg Information-Centric Networking Zurich E/F RTG rtgarea Routing Area Open Meeting Vevey 1/2 TSV quic QUIC WG 1300-1500 Afternoon Session I Zurich B ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Zurich G SEC acme Automated Certificate Management = Environment WG Zurich A TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Zurich D SEC saag Security Area Open Meeting 1740-1840 Afternoon Session III Zurich B RTG *** roll Routing Over Low power and Lossy = networks WG FRIDAY, March 31, 2017 0900-1130 Morning Session I Vevey 1/2 ART httpbis Hypertext Transfer Protocol WG Zurich E/F INT ipwave IP Wireless Access in Vehicular = Environments WG Zurich A OPS anima Autonomic Networking Integrated Model = and Approach WG Zurich C SEC oauth Web Authorization Protocol WG 1150-1320 Afternoon Session I Zurich C ART *** core Constrained RESTful Environments WG From nobody Thu Mar 9 22:18:15 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054271294CE for ; Thu, 9 Mar 2017 22:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 ZpHbNiFkB_fB for ; Thu, 9 Mar 2017 22:18:12 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0100.outbound.protection.outlook.com [104.47.41.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1D812940B for ; Thu, 9 Mar 2017 22:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=89bZ9l77EOUUPDhzy2GhEXx9viT9pi4gKL5PA2k6h1w=; b=TuADFyAX2/lEWON3tD6bQxQwIAaI1umW2vHszKBot8r3FxfAvkx+od/Nws+25JHm0z0UvxTQrpMQBUI6J72u2bQ9KjYB8JBk9Cl7jZHNLibSDz7cjOSnE20bo+BlXBrbHe4t1hGzDdJr4bZMyXAqSS91zxTJZR6T0YYwwbUh6i0= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0503.namprd21.prod.outlook.com (10.172.122.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.0; Fri, 10 Mar 2017 06:18:10 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.0947.007; Fri, 10 Mar 2017 06:18:10 +0000 From: Mike Jones To: "cose@ietf.org" Thread-Topic: Cleaner version of Using RSA Algorithms with COSE Messages specification Thread-Index: AdKZY6D9DJIe3FBlQnu7+6bDI0n5/Q== Date: Fri, 10 Mar 2017 06:18:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.93.167] x-ms-office365-filtering-correlation-id: b23312e9-1d9b-480d-eb15-08d4677d39cd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR21MB0503; x-microsoft-exchange-diagnostics: 1; CY4PR21MB0503; 7:TnfoQW+CxEiokrLTexdIJVOBNohRUhQlA6AyFk/WXcC3NcDofT94S4cyPKGK5IWZvAgAMirOZiO3/V1W1LWylckCVRiTvXgsgw6NAAXMddo+S6LGh3e+Z5GjGCAVtB5p4Oep3QBVDkat3wR0vgd3Acxci3rLt9pzdAkM9qQ0mPFuDG6wz9i/8KHcuTUa03hrG83laEQXeyS+QP5LNCg6NelEBkyOLS8NfSmEHFhZSxzDRoRrF1AiI4Jcs7trTx33fdwhNamwzxVyfIeXzq4bx/uok/DgamQg6tNIk//W4076ZhJblJFv1xjZMi3ZSTXVJnytQW2+H0MXQgVzo3+oOnqxfu/lQZPqXhWnBm1Ku9I= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:CY4PR21MB0503; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0503; x-forefront-prvs: 02426D11FE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39860400002)(39410400002)(39450400003)(39850400002)(209900001)(7906003)(86362001)(74316002)(7736002)(66066001)(15650500001)(5640700003)(122556002)(6116002)(4326008)(236005)(8936002)(966004)(25786008)(54356999)(7696004)(6916009)(189998001)(2351001)(9686003)(2501003)(86612001)(39060400002)(1730700003)(54896002)(53936002)(790700001)(102836003)(10290500002)(81166006)(53376002)(6436002)(110136004)(2900100001)(5660300001)(38730400002)(3846002)(6506006)(3660700001)(55016002)(8676002)(7110500001)(2420400007)(6306002)(2906002)(77096006)(10090500001)(606005)(33656002)(99286003)(50986999)(8990500004)(5005710100001)(3280700002)(5630700001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0503; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504C6E2679CFD7E985EAAD3F5200CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2017 06:18:10.2209 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0503 Archived-At: Cc: "kathleen.moriarty.ietf@gmail.com" Subject: [COSE] Cleaner version of Using RSA Algorithms with COSE Messages specification X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 06:18:14 -0000 --_000_CY4PR21MB0504C6E2679CFD7E985EAAD3F5200CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've published an updated version of the "Using RSA Algorithms with COSE Me= ssages" specification with a number of editorial improvements. Changes wer= e: * Reorganized the security considerations. * Flattened the section structure. * Applied wording improvements suggested by Jim Schaad. The specification is available at: * https://tools.ietf.org/html/draft-jones-cose-rsa-02 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-jones-cose-rsa-02.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1653 and = as @selfissued. --_000_CY4PR21MB0504C6E2679CFD7E985EAAD3F5200CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve published an updated version of the ̶= 0;Using RSA Algorithms with COSE Messages” specification with a numbe= r of editorial improvements.  Changes were:

  • Reorganized the security considerations.
  • Flatten= ed the section structure.
  • Applied wording improvements= suggested by Jim Schaad.

 

The specification is available at:

  • <= a href=3D"https://tools.ietf.org/html/draft-jones-cose-rsa-02">https://tool= s.ietf.org/html/draft-jones-cose-rsa-02

 

An HTML-formatted version is also available at:=

  • <= a href=3D"http://self-issued.info/docs/draft-jones-cose-rsa-02.html">http:/= /self-issued.info/docs/draft-jones-cose-rsa-02.html

    •  

            &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

     

    P.S.  This notice was also posted at http://self-issued.info/?p=3D1653 and as @selfissued.

     

--_000_CY4PR21MB0504C6E2679CFD7E985EAAD3F5200CY4PR21MB0504namp_-- From nobody Thu Mar 9 22:20:14 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBEA12940B for ; Thu, 9 Mar 2017 22:20:13 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 Me5mTq7efqAL for ; Thu, 9 Mar 2017 22:20:11 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0120.outbound.protection.outlook.com [104.47.38.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6584A127A90 for ; Thu, 9 Mar 2017 22:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=St13N/Jf1fmiUZ1wo8I3/W58FHYVmqtdxyXDS73+WGI=; b=ZyFPn9BGGd07macSCIBgewaMlmtKUxCZZASeJq3HobCSzxjuYxgeYjQghkdHcf1BIljKk8YbiudWbqpHQO49WLvGK/wxogCfaaa3QICkWobbLqYl30gcsccgmITX9so+Z3OZAHxiKu5aHegG0aMHGHf4HTm6eWBuhwp/z5dM7gU= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0501.namprd21.prod.outlook.com (10.172.122.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.0; Fri, 10 Mar 2017 06:20:09 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.0947.007; Fri, 10 Mar 2017 06:20:09 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: draft-jones-cose-rsa Thread-Index: AdJt8A6WCR6ocoRXTl2j84aobKNTqQAOYB4ACs3QYgA= Date: Fri, 10 Mar 2017 06:20:09 +0000 Message-ID: References: <047c01d26e29$90adf600$b209e200$@augustcellars.com> In-Reply-To: <047c01d26e29$90adf600$b209e200$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.93.167] x-ms-office365-filtering-correlation-id: 52dfa398-a1da-4975-6624-08d4677d80c7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR21MB0501; x-microsoft-exchange-diagnostics: 1; CY4PR21MB0501; 7:uv8xjjWVy4oTFRyyvcnspWRN+dxJN39x1jtY3qc2WjIZcUltrmWQQ4i050rWdw2KOdukm8+S32qwX1NDaoVzUy4KWt44ywLtaYIkIP7Y1gNc7w1L3aBmY6pA3/lEk6clr8O51Q6TNa40ejdqRDE1/xrVXzjLqQgw2QGefKUgHjvDd6DWcuxGz4Jdw31x/Qfr/7NYR71nypCBKB4UxCOK8nd7fwmdnBfoSBokZCXHcG5RKwx0NdT/ldOnM2dyZCTh0YH3zxg9iUL2zrl+fgBVrFQ/+SJNCC1b7cqDx6al6wR9nWmHjq1ZoDPFfhM7/472kombhlSrmPaAABadCMsxTlCkYudVuT9bCIsYLBzBNCI= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:CY4PR21MB0501; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0501; x-forefront-prvs: 02426D11FE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39840400002)(39850400002)(39410400002)(39450400003)(43784003)(377454003)(13464003)(8990500004)(5005710100001)(6246003)(55016002)(53546006)(229853002)(76176999)(86612001)(8936002)(38730400002)(236005)(77096006)(6506006)(25786008)(33656002)(2900100001)(790700001)(66066001)(6116002)(19609705001)(50986999)(2950100002)(3846002)(189998001)(122556002)(102836003)(2501003)(99286003)(81166006)(4326008)(3280700002)(9686003)(8676002)(74316002)(7736002)(230783001)(53936002)(54356999)(86362001)(2906002)(6306002)(54896002)(5660300001)(10290500002)(6436002)(7696004)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0501; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504AFDE373BDF1C9F3DD09CF5200CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2017 06:20:09.3635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0501 Archived-At: Cc: "draft-jones-cose-rsa@tools.ietf.org" Subject: Re: [COSE] draft-jones-cose-rsa X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 06:20:13 -0000 --_000_CY4PR21MB0504AFDE373BDF1C9F3DD09CF5200CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft -02 incorporates the issue resolutions discussed below. Thanks again= for taking the time to do a thorough review, Jim. Replies describing spec= ific resolutions applied follow inline. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Friday, January 13, 2017 9:47 PM To: Mike Jones ; cose@ietf.org Cc: draft-jones-cose-rsa@tools.ietf.org Subject: RE: draft-jones-cose-rsa From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, January 13, 2017 2:55 PM To: Jim Schaad >; cos= e@ietf.org Cc: draft-jones-cose-rsa@tools.ietf.org Subject: RE: draft-jones-cose-rsa Thanks for taking the time to write this up, Jim. Responses are inline bel= ow. -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Sunday, January 01, 2017 3:34 PM To: draft-jones-cose-rsa@tools.ietf.org Cc: jose@ietf.org Subject: [jose] draft-jones-cose-rsa Comments: 0. Should this be done in curdle rather than as AD sponsored? I had requested AD sponsorship because of how simple the draft is. It regi= sters a few numbers in registries being created by the COSE Messages draft = and defines the layout of RSA keys (in a way that's completely parallel to = the JOSE layout, but using CBOR rather than JSON). It uses no new algorith= ms. It didn't seem to rise to the occasion of needing a working group - es= pecially when there remain COSE WG members such as Jim willing to take the = time to give constructive feedback. [JLS] Getting people to from this old WG list can still be done even if it = is done in a different working group. That is what the idea of cross posti= ng is all about. Both individuals who have made substantive comments are o= n both mailing lists anyway so doing in a different group does not close ou= t either of them. The amount of time a draft takes to finish depends as mu= ch on you as a chair for most steps. It is possible that the Curdle group = would not want the draft, but asking is still reasonable. [mbj] I seem to be getting useful feedback by posting the COSE list, as Kat= hleen had suggested. 1. As per previous mail, remove values assignments in tables 1, 2, and 3 u= nless you have cleared them with the appropriate registry experts. I am le= ss worried about table 4 but you should clear that as well. I looked for the designated experts to consult with but the IANA COSE regis= tries don't seem to have been created yet, nor have the experts been public= ly named. Once they are, I will certainly consult with them. I don't plan= to remove the values since having proposed assignments is more useful to i= mplementers than having none. [JLS] For interop testing - that is what the private values are for. [mbj] I have left the proposed values in place, pending discussions with th= e designated experts, once they are announced. 2. Kill RSAES-OAP w/ SHA-1. We are not doing SHA-1 currently with any of = the CBOR algorithms. In section 3.1.1.1 - what are the properties that are= needed here for SHA-1 so we can ensure that the statement is true. Also, = rename this to be s/ SHA-1 not w/ Default. There are no defaults for COSE. RSAES-OAEP with the default parameters defined in Section A.2.1 of RFC 3447= is included for the same reason that it is in RFC 7518 - because it's the = mostly widely implemented set of OAEP parameter choices, facilitating inter= operation of implementations. Particularly given that RSAES-PKCS1-v1_5 is = not included, RSA interop considerations lead to the decision to retain thi= s algorithm. In the next revision, I will be clear that the defaults come from RFC 3447. [JLS] There is absolutely no reason to even say that default values exist h= ere. COSE does not have the concept of defaults. Not having SHA-1 does no= t seem to be a problem for PSS, why would it be a problem here? [mbj] As promised, I am now even clearer that they are RFC 3447-specified d= efaults. The JOSE implementation experience with RSA-OAEP-SHA256 is that i= t's not available on many development platforms, whereas RSA-OAEP is. Enab= ling implementers to use the defaults has interop benefits for COSE, just l= ike it did for JOSE. 3. Text in 3.1.1.1 and 2.1.1 should be more consistent in how it is writte= n. Suggestions for specific textual additions and/or changes would be helpful = here. [mbj] I have completely reworked and consolidated the Security Consideratio= ns in ways intended to address this feedback. 4. in the abstract be more specific about which RSA algorithms are being su= pported. For example, you are not doing 1.5 or KEM. OK - will do [mbj] Done 5. Why does 3.1.1.1 have a size and 2.1.1 not have one. This should be co= nsistent. I agree with this suggestion. I'll make sure that the minimum size applies= to all uses of RSA algorithms. [mbj] Addressed as part of restructuring the security considerations. 6. section 3.1.1.1 should be encryption operation not decryption operation= . OK [mbj] It now says "cryptographic operation", because the guidance now appli= es to signatures as well as encryption. 7. Section 3.1.1.1 - this text does not make sense "One potential denial o= f service operation is to provide encrypted objects using either abnormally long or oddly sized RSA modulus values." Should probably refer to keys not encrypted objects. OK [mbj] Done (in reworked text) 8. There is a requirement of minimum encoding lengths - what purpose does = this serve? Is there a security problem here or is it just a nice to have = because of message size? This is there for the same reason that it is present for JWKs - to facilita= te interoperation of implementations by having a standard representation fo= r each key, rather enabling a multiplicity of different representations to = be used - which could cause interop problems. [JLS] Not sold. [mbj] Having a standard representation also reduces the variance in data fo= rmats that implementations have to parse, potentially improving interop. A= lso, having a canonical representation has proven useful for JOSE. I will = likely prove useful for COSE for the same reasons. 9. Missing some security considerations. Specific suggested text would be appreciated, as always. [mbj] What would you like to see added? 10 Section 2.1.1 s/hash functions are not truncated/hash function outputs a= re not truncated/ Agreed [mbj] Done Thanks agai= n, -- Mike --_000_CY4PR21MB0504AFDE373BDF1C9F3DD09CF5200CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft -02 incorporates= the issue resolutions discussed below.  Thanks again for taking the t= ime to do a thorough review, Jim.  Replies describing specific resolut= ions applied follow inline.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

From: Jim Schaad [mailto:ietf@augustcellars.c= om]
Sent: Friday, January 13, 2017 9:47 PM
To: Mike Jones <Michael.Jones@microsoft.com>; cose@ietf.org Cc: draft-jones-cose-rsa@tools.ietf.org
Subject: RE: draft-jones-cose-rsa

 

 

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, January 13, 2017 2:55 PM
To: Jim Schaad <ietf@au= gustcellars.com>; cose@ietf.org
Cc: draft-jon= es-cose-rsa@tools.ietf.org
Subject: RE: draft-jones-cose-rsa

 

Thanks for taking the time to write this up, Jim.=   Responses are inline below.

 

-----Original Message-----
From: jose [mailto:jose-bounces@ie= tf.org] On Behalf Of Jim Schaad
Sent: Sunday, January 01, 2017 3:34 PM
To: draft-jones-cose= -rsa@tools.ietf.org
Cc: jose@ietf.org
Subject: [jose] draft-jones-cose-rsa

 

Comments:

 

0.  Should this be done in curdle rather tha= n as AD sponsored?

 

I had requested AD spo= nsorship because of how simple the draft is.  It registers a few numbe= rs in registries being created by the COSE Messages draft and defines the l= ayout of RSA keys (in a way that’s completely parallel to the JOSE layout, but using CBOR rather than JSON).  It us= es no new algorithms.  It didn’t seem to rise to the occasion of= needing a working group – especially when there remain COSE WG membe= rs such as Jim willing to take the time to give constructive feedback.

 

[JLS] Getting people to fr= om this old WG list can still be done even if it is done in a different wor= king group.  That is what the idea of cross posting is all about. = ; Both individuals who have made substantive comments are on both mailing lists anyway so doing in a different group does not cl= ose out either of them.  The amount of time a draft takes to finish de= pends as much on you as a chair for most steps.  It is possible that t= he Curdle group would not want the draft, but asking is still reasonable.

 

[mbj] I seem to be get= ting useful feedback by posting the COSE list, as Kathleen had suggested.

 

1.  As per previous mail, remove values assi= gnments in tables 1, 2, and 3 unless you have cleared them with the appropr= iate registry experts.  I am less worried about table 4 but you should= clear that as well.

 

I looked for the desig= nated experts to consult with but the IANA COSE registries don’t seem= to have been created yet, nor have the experts been publicly named.  = Once they are, I will certainly consult with them.  I don’t plan to remove the values since having proposed assignments = is more useful to implementers than having none.

 

[JLS] For interop testing = – that is what the private values are for.

 

[mbj] I have left t= he proposed values in place, pending discussions with the designated expert= s, once they are announced.

 

2.  Kill RSAES-OAP w/ SHA-1.  We are no= t doing SHA-1 currently with any of the CBOR algorithms.  In section 3= .1.1.1 - what are the properties that are needed here for SHA-1 so we can e= nsure that the statement is true.  Also, rename this to be s/ SHA-1 not w/ Default.  There are no defaults for COSE.<= /o:p>

 

RSAES-OAEP with the de= fault parameters defined in Section A.2.1 of RFC 3447 is included for the s= ame reason that it is in RFC 7518 – because it’s the mostly wid= ely implemented set of OAEP parameter choices, facilitating interoperation of implementations.  Particularly given that RSAES-PKC= S1-v1_5 is not included, RSA interop considerations lead to the decision to= retain this algorithm.

 

In the next revision, = I will be clear that the defaults come from RFC 3447.

 

[JLS] There is absolutely = no reason to even say that default values exist here.  COSE does not h= ave the concept of defaults.  Not having SHA-1 does not seem to be a p= roblem for PSS, why would it be a problem here?

 

[mbj] As promised, I a= m now even clearer that they are RFC 3447-specified defaults.  The JOS= E implementation experience with RSA-OAEP-SHA256 is that it’s not ava= ilable on many development platforms, whereas RSA-OAEP is.  Enabling implementers to use the defaults has interop benefits f= or COSE, just like it did for JOSE.

 

3.  Text in 3.1.1.1 and 2.1.1 should be more= consistent in how it is written.

 

Suggestions for specif= ic textual additions and/or changes would be helpful here.

 

[mbj] I have comple= tely reworked and consolidated the Security Considerations in ways intended= to address this feedback.

 

4. in the abstract be more specific about which R= SA algorithms are being supported.  For example, you are not doing 1.5= or KEM.

 

OK – will do

 

[mbj] Done<= /span>

 

5.  Why does 3.1.1.1 have a size and 2.1.1 n= ot have one.  This should be consistent.

 

I agree with this suggestion.  I’ll ma= ke sure that the minimum size applies to all uses of RSA algorithms.

 

[mbj] Addressed as = part of restructuring the security considerations.

 

6.  section 3.1.1.1 should be encryption ope= ration not decryption operation.

 

OK

 

[mbj] It now says R= 20;cryptographic operation”, because the guidance now applies to sign= atures as well as encryption.

 

7.  Section 3.1.1.1 - this text does not mak= e sense "One potential denial of service

   operation is to provide encrypted ob= jects using either abnormally

   long or oddly sized RSA modulus valu= es."   Should probably refer to keys

not encrypted objects.

 

OK

 

[mbj] Done (in reworke= d text)

 

8.  There is a requirement of minimum encodi= ng lengths - what purpose does this serve?  Is there a security proble= m here or is it just a nice to have because of message size?

 

This is there for the = same reason that it is present for JWKs – to facilitate interoperatio= n of implementations by having a standard representation for each key, rath= er enabling a multiplicity of different representations to be used – which could cause interop problems.

 

[JLS] Not sold.=

 

[mbj] Having a stan= dard representation also reduces the variance in data formats that implemen= tations have to parse, potentially improving interop.  Also, having a = canonical representation has proven useful for JOSE.  I will likely prove useful for COSE for the same reasons.<= o:p>

 

9. Missing some security considerations.

 

Specific suggested tex= t would be appreciated, as always.

 

[mbj] What would yo= u like to see added?

 

10 Section 2.1.1 s/hash functions are not truncat= ed/hash function outputs are not truncated/

 

Agreed

 

[mbj] Done

 

   &nb= sp;            =             &nb= sp;            =             &nb= sp;          Thanks again,

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 

--_000_CY4PR21MB0504AFDE373BDF1C9F3DD09CF5200CY4PR21MB0504namp_-- From nobody Fri Mar 17 09:50:05 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB0A1294A5 for ; Fri, 17 Mar 2017 09:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.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 jEbJjjqfprxt for ; Fri, 17 Mar 2017 09:50:02 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::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 A17301201F2 for ; Fri, 17 Mar 2017 09:50:02 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id a12so28077863ota.0 for ; Fri, 17 Mar 2017 09:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Y+exmChdXkBWXMrb9W85yWrlPlC8ixDn7juHUouUa1U=; b=njlrrQb0/GpM+UUZvYxLNycbjduLt0QyBBPWwMq3jVe9Coa4u9ww+7GcxGuLItahZ8 sas/2NZz30ktCX+RUUqBqequwYjspAKt8HQ/3ZqueDb+kS54WglALFgEaIL5cix77mSS 1H+eDRaH6XtRnxUr24AH11YM9+TD5UCPzIizBykSWnKrQtWRvp8u4xE2tVAd4FHyIgWt Y7QV5zn4Axv04FESFJcaIds/yciGGGIK2VS+CvB4Yx8QkU9n3li5E+ej72EKOorPQS61 BkTe0FLeFwwa5yBM1KcCqogom0UMEmFeXDLZ9CysRSxggtwlfoBdnoZFxyRhRza0qoyd YbHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Y+exmChdXkBWXMrb9W85yWrlPlC8ixDn7juHUouUa1U=; b=EzUIXP1tfhpE9JZ5Of7DxIxzW2vcoG/tCSNqQYXwpYvbyBBkv0x9iHfnZggNUbMtSk KoGoG4UQjGtaP0Isaw/MExPh7iyOwnOuXeLaVNHSuQ5WfFiQBPZ6W2M/az/4J7KCh64J VveG7aC5LX+jCCQDRiR74rEVlaRSMF1aBQHXH/mSgp3hs+/OhWAdW3w/09XdrAGUL2Nf fcLDiTiyhBsM0H6vTcQrkeW95ofY53UQUJo30S0F272g93ZftI0jbPDCTcca8ba/TpGT Zz9lnClDVFCMBYv64OKuy5I0l2pmqvqPqJ/ToOw57ZDzwC1C6RQ0BrVst/dSyDWmFFbZ QrEg== X-Gm-Message-State: AFeK/H1jlLtXdcrmrRbfW0Q/rT77PSkF+r2jGv1FJfr8VsTQjEqM1qMk1DzOFtndc0ApNRbAwOcHvSbt3k+QSA== X-Received: by 10.157.51.50 with SMTP id f47mr8901662otc.192.1489769401679; Fri, 17 Mar 2017 09:50:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.125.40 with HTTP; Fri, 17 Mar 2017 09:50:01 -0700 (PDT) From: Samuel Erdtman Date: Fri, 17 Mar 2017 17:50:01 +0100 Message-ID: To: cose , Jim Schaad Content-Type: multipart/alternative; boundary=001a113ef86cfc16c6054aeff73d Archived-At: Subject: [COSE] Authentication tag X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 16:50:04 -0000 --001a113ef86cfc16c6054aeff73d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi I=C2=B4m working on a JavaScript implementation of the COSE msg specificati= on, currently working on the GCM encryption. In the nodejs crypto environment the authentication tag is set separately i.e. a specific setAuthTag call. I looked into openssl and could see that that was the case there too. In the examples provided with the COSE specification I could find out that the auth tag is appends to the end of the ciphertext. I tried to find this described in the COSE specification but could not find it. It might be described in some refereed specification but it was not obvious to me at least. If it is not to late I would suggest that authentication tag is lifted out from the ciphertext and into the unprotected header similar to IV. Or that it is explicitly described that the authentication tag should be appended to the ciphertext. Cheers Samuel Erdtman --001a113ef86cfc16c6054aeff73d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

I=C2=B4m wo= rking on a JavaScript implementation of the COSE msg specification, current= ly working on the GCM encryption.

In the nodejs crypto environment t= he authentication tag is set separately i.e. a specific setAuthTag call. I = looked into openssl and could see that that was the case there too.

=
In the examples provided with the COSE specification I could find out= that the auth tag is appends to the end of the ciphertext.

I = tried to find this described in the COSE specification but could not find i= t. It might be described in some refereed specification but it was not obvi= ous to me at least.

If it is not to late I would suggest that = authentication tag is lifted out from the ciphertext and into the unprotect= ed header similar to IV. Or that it is explicitly described that the authen= tication tag should be appended to the ciphertext.

Cheers
<= /div>Samuel Erdtman


--001a113ef86cfc16c6054aeff73d-- From nobody Fri Mar 17 10:10:51 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0303F1294FB for ; Fri, 17 Mar 2017 10:10:50 -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 NlU1-BL52oWl for ; Fri, 17 Mar 2017 10:10:48 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 57B7A1294CD for ; Fri, 17 Mar 2017 10:10:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 7134F1F46B; Fri, 17 Mar 2017 19:10:47 +0200 (EET) 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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id XRbIIPkyEnMs; Fri, 17 Mar 2017 19:10:47 +0200 (EET) 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 2D809C4; Fri, 17 Mar 2017 19:10:47 +0200 (EET) Date: Fri, 17 Mar 2017 19:10:40 +0200 From: Ilari Liusvaara To: Samuel Erdtman Cc: cose , Jim Schaad Message-ID: <20170317171039.GB27219@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [COSE] Authentication tag X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 17:10:50 -0000 On Fri, Mar 17, 2017 at 05:50:01PM +0100, Samuel Erdtman wrote: > Hi > > I´m working on a JavaScript implementation of the COSE msg specification, > currently working on the GCM encryption. > > In the nodejs crypto environment the authentication tag is set separately > i.e. a specific setAuthTag call. I looked into openssl and could see that > that was the case there too. > > In the examples provided with the COSE specification I could find out that > the auth tag is appends to the end of the ciphertext. Well, COSE specification refers to RFC 5116 for definition of AE and AEAD, and that framework only allows single ciphertext output, which as consequence must contain the tag. (How it contains the tag is actually algorithm-dependent, but most have it at the end). -Ilari From nobody Fri Mar 17 10:27:48 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B326129515 for ; Fri, 17 Mar 2017 10:27:46 -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, HTML_MESSAGE=0.001, 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 1E0eGd7O7oWK for ; Fri, 17 Mar 2017 10:27:44 -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 607E71294D7 for ; Fri, 17 Mar 2017 10:27:44 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F8_01D29F09.161AE8B0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1489771653; h=from:subject:to:date:message-id; bh=d5CAQdMxeKVC5yllzRc+gHJ20nzj8UDfgGBy2JDgzlg=; b=JvIjb+saFD04eKnJxN2aXiSs0lQcdHzGwc8UUYpUcWt4fv0Fbu2++XDDU3q28ATtcmA8EOgWMi2 cc8O+WsKNtFrUbsG6bsHjDW31auDmm4TQfsNhnr3XBIhbzWZ923qeYXrSehi3DMDAROU4pJEgdZ4K duRRsnTc3UZj5vsHKDM7+R72wAeiV5vwu+leU5A4pTXQMAEqbA0SxogfgNgsXLuX5YeYcfVbaYaTX 0htxOl4SD6TcZNgp1DtUiPReBbb3/cfij3JTI4umu9jcdyYHEpH+iuJuc1UmBTh2V7dEhvBv62jXP X8ikiv0WHS1zGZyPJR1N3/4VBArLKRNjXpTg== 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, 17 Mar 2017 10:27:32 -0700 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 17 Mar 2017 10:25:15 -0700 From: Jim Schaad To: 'Samuel Erdtman' , 'cose' References: In-Reply-To: Date: Fri, 17 Mar 2017 10:27:29 -0700 Message-ID: <00f701d29f43$c278fd60$476af820$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHJyY/ZCPv2uIyenJalNKBf3teWxKGq9E1g X-Originating-IP: [192.168.0.98] Archived-At: Subject: Re: [COSE] Authentication tag X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 17:27:46 -0000 ------=_NextPart_000_00F8_01D29F09.161AE8B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >From Section 10: =20 COSE restricts the set of legal content encryption algorithms to those = that support authentication both of the content and additional data. The = encryption process will generate some type of authentication value, but = that value may be either explicit or implicit in terms of the algorithm = definition. For simplicity sake, the authentication code will normally = be defined as being appended to the cipher text stream. The encryption = functions are: =20 =20 From: Samuel Erdtman [mailto:samuel@erdtman.se]=20 Sent: Friday, March 17, 2017 9:50 AM To: cose ; Jim Schaad Subject: Authentication tag =20 Hi=20 I=C2=B4m working on a JavaScript implementation of the COSE msg = specification, currently working on the GCM encryption. In the nodejs crypto environment the authentication tag is set = separately i.e. a specific setAuthTag call. I looked into openssl and = could see that that was the case there too. In the examples provided with the COSE specification I could find out = that the auth tag is appends to the end of the ciphertext. I tried to find this described in the COSE specification but could not = find it. It might be described in some refereed specification but it was = not obvious to me at least. If it is not to late I would suggest that authentication tag is lifted = out from the ciphertext and into the unprotected header similar to IV. = Or that it is explicitly described that the authentication tag should be = appended to the ciphertext. Cheers Samuel Erdtman =20 ------=_NextPart_000_00F8_01D29F09.161AE8B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

From Section = 10:

 

COSE restricts the set of legal = content encryption algorithms to those that support authentication both = of the content and additional data. The encryption process will generate = some type of authentication value, but that value may be either explicit = or implicit in terms of the algorithm definition. For simplicity sake, the authentication code will = normally be defined as being appended to the cipher text stream. = The encryption functions are:

 

 

From:<= /b> = Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Friday, March = 17, 2017 9:50 AM
To: cose <cose@ietf.org>; Jim Schaad = <ietf@augustcellars.com>
Subject: Authentication = tag

 

Hi =

I=C2=B4m working on a JavaScript = implementation of the COSE msg specification, currently working on the = GCM encryption.

In the nodejs crypto environment the = authentication tag is set separately i.e. a specific setAuthTag call. I = looked into openssl and could see that that was the case there = too.

In the examples provided with the COSE = specification I could find out that the auth tag is appends to the end = of the ciphertext.

I tried to find this described in the = COSE specification but could not find it. It might be described in some = refereed specification but it was not obvious to me at = least.

If it is not to late I would suggest that = authentication tag is lifted out from the ciphertext and into the = unprotected header similar to IV. Or that it is explicitly described = that the authentication tag should be appended to the = ciphertext.

Cheers

Samuel = Erdtman

 

------=_NextPart_000_00F8_01D29F09.161AE8B0-- From nobody Sat Mar 18 13:08:15 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512F012709D for ; Sat, 18 Mar 2017 13:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.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 JAE92KPIQCUL for ; Sat, 18 Mar 2017 13:08:10 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (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 8E575129434 for ; Sat, 18 Mar 2017 13:08:10 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id x37so113946714ota.2 for ; Sat, 18 Mar 2017 13:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PtZO2ZLw8k49ORWq3v1ZArLENfjsZV1cuUZ+wmjvXCM=; b=fSfAkLPm54C3RnitsYWt2JxUTUaA3WM+oOw/FLz2aObXxzXX7FXpQcgVXebNQrmTEz W2uASKgFSccxLtjp0VyuxDMN9sSvdxjFjV4CAAOfTbfKq9wwn33Vk4re6/8vdzEujxNw cUaQeURG258p+UFmfsx7Y1w9W2qzkg84brnOwggfBSgI0iKQjG6Hu/aZOSqw+JUMKaJC yiNB8ifOYkmcXegEcG3hNM5hfmSjzSlYyWl5Fvne4mAwDwW+iRvhRevdgDRhVAC2TjDQ ZmVmxhdZVoBpKHxFSYk7D/kDKxIt4vnBYwZ6XhowpboA9ZML6nzd3DYGbXXhJdNw4W6N jmlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PtZO2ZLw8k49ORWq3v1ZArLENfjsZV1cuUZ+wmjvXCM=; b=ngcBx1URP2Gxxoolqz3qvA5JUO/hCMsfwzKq5JfsPozurq+zAzyXBwTfNkWlr6f03v XsNM4eRb3oxiGAoPVxOTLT8lvIjzOZqESj3acMLU8l1bLo4AlBoun9Y8wKDkOpZXn/zZ F4D7JwSDsZuxFcsdN7DsKRQB5XL4PW1dk9ERuJFQSFxjnYcf4izgf645ZLJdgkufCiLQ cJDB1djEuWShgf12+vAYoE+6F8WT8Hrdwmy9XRneF3sTt/dYdO/HyNFAHCa3/OQX+FJr DMucW8bh1ZhmJR13P97RwROvolX0t9iBVJbGE3QSx2WrIGElLWhX/sg2vHCN/jq5bkgV X5tA== X-Gm-Message-State: AFeK/H1cD6b9+Xr21AMW2Aek6MBKoytwk3cjvYtJ5A/GFeF9RB0n/qmcDzlAO58KUDp3I8H4y6L0p7qZ2U9LWQ== X-Received: by 10.157.66.14 with SMTP id q14mr10409014ote.210.1489867689707; Sat, 18 Mar 2017 13:08:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.125.40 with HTTP; Sat, 18 Mar 2017 13:08:09 -0700 (PDT) In-Reply-To: <00f701d29f43$c278fd60$476af820$@augustcellars.com> References: <00f701d29f43$c278fd60$476af820$@augustcellars.com> From: Samuel Erdtman Date: Sat, 18 Mar 2017 21:08:09 +0100 Message-ID: To: Jim Schaad , ilariliusvaara@welho.com Cc: cose Content-Type: multipart/alternative; boundary=f4030437951c686245054b06da90 Archived-At: Subject: Re: [COSE] Authentication tag X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 20:08:13 -0000 --f4030437951c686245054b06da90 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Jim and Ilari for the quick replies. So if I understand it correctly RFC 5116 defines AE and AEAD with the requirement to bundle the tag with the ciphertext, so it would not be allowed to put the tag in the COSE headers. Section 10 Content Encryption Algorithms, gives a hint of where to find the tag, 'normally' appended. Forgive me my ignorance, but does GCM have a more normative requirement on the location of the tag in a ciphertext? If GCM does not mandate the location of the tag in the ciphertext and we cannot put it in a header attribute then I would like more explicit language about where to find/put the tag. Once again thanks for the quick and enlightening reply. Cheers //Samuel On Fri, Mar 17, 2017 at 6:27 PM, Jim Schaad wrote: > From Section 10: > > > > COSE restricts the set of legal content encryption algorithms to those > that support authentication both of the content and additional data. The > encryption process will generate some type of authentication value, but > that value may be either explicit or implicit in terms of the algorithm > definition. For simplicity sake, the authentication code will normally be > defined as being appended to the cipher text stream. The encryption > functions are: > > > > > > *From:* Samuel Erdtman [mailto:samuel@erdtman.se] > *Sent:* Friday, March 17, 2017 9:50 AM > *To:* cose ; Jim Schaad > *Subject:* Authentication tag > > > > Hi > > I=C2=B4m working on a JavaScript implementation of the COSE msg specifica= tion, > currently working on the GCM encryption. > > In the nodejs crypto environment the authentication tag is set separately > i.e. a specific setAuthTag call. I looked into openssl and could see that > that was the case there too. > > In the examples provided with the COSE specification I could find out tha= t > the auth tag is appends to the end of the ciphertext. > > I tried to find this described in the COSE specification but could not > find it. It might be described in some refereed specification but it was > not obvious to me at least. > > If it is not to late I would suggest that authentication tag is lifted ou= t > from the ciphertext and into the unprotected header similar to IV. Or tha= t > it is explicitly described that the authentication tag should be appended > to the ciphertext. > > Cheers > > Samuel Erdtman > > > --f4030437951c686245054b06da90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Jim and Ilari for the quick replies.
<= br>
So if I understand it correctly RFC 5116 defines AE and AEAD wit= h the requirement to bundle the tag with the ciphertext, so it would not be= allowed to put the tag in the COSE headers.

Section 10 Conten= t Encryption Algorithms, gives a hint of where to find the tag, 'normal= ly' appended. Forgive me my ignorance, but does GCM have a more normati= ve requirement on the location of the tag in a ciphertext?

If GCM does not mandate the location of the tag in the ciphertext and we c= annot put it in a header attribute then I would like more explicit language= about where to find/put the tag.

Once again thanks for t= he quick and enlightening reply.

Cheers
//S= amuel


On Fri, Mar 17, 2017 at 6:27 PM, Jim Schaad <ietf@augustcellars.com> wrote:

From Secti= on 10:

=C2=A0=

COSE restricts the set of legal content e= ncryption algorithms to those that support authentication both of the conte= nt and additional data. The encryption process will generate some type of a= uthentication value, but that value may be either explicit or implicit in t= erms of the algorithm definition. For simplicity = sake, the authentication code will normally be defined as being appended to= the cipher text stream. The encryption functions are:=

=C2=A0

=C2=A0

From: Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Fr= iday, March 17, 2017 9:50 AM
To: cose <cose@ietf.org>; Jim Schaad <ietf@augustcellars.com= >
Subject: Authentication tag

=C2=A0<= /p>

Hi

I=C2=B4m working on a JavaScript implementation of t= he COSE msg specification, currently working on the GCM encryption.

= In the nodejs crypto environment the authentication tag is set separately i= .e. a specific setAuthTag call. I looked into openssl and could see that th= at was the case there too.

In the examples provided with the COSE specifi= cation I could find out that the auth tag is appends to the end of the ciph= ertext.

I tried to find this described in the COSE specification but coul= d not find it. It might be described in some refereed specification but it = was not obvious to me at least.

If it is not to late I would suggest that= authentication tag is lifted out from the ciphertext and into the unprotec= ted header similar to IV. Or that it is explicitly described that the authe= ntication tag should be appended to the ciphertext.

=

Cheers

Samuel Erdtman

=C2=A0


--f4030437951c686245054b06da90-- From nobody Sat Mar 18 14:09:27 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9DA1270AC for ; Sat, 18 Mar 2017 14:09:26 -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 GsvCBn22BUmC for ; Sat, 18 Mar 2017 14:09:23 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id A08EE12943F for ; Sat, 18 Mar 2017 14:09:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 0F4861F125; Sat, 18 Mar 2017 23:09:22 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 6LWyFfmxiF-5; Sat, 18 Mar 2017 23:09:21 +0200 (EET) 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-smtp3.welho.com (Postfix) with ESMTPSA id BE5C92310; Sat, 18 Mar 2017 23:09:21 +0200 (EET) Date: Sat, 18 Mar 2017 23:09:14 +0200 From: Ilari Liusvaara To: Samuel Erdtman Cc: Jim Schaad , cose Message-ID: <20170318210914.GA28878@LK-Perkele-V2.elisa-laajakaista.fi> References: <00f701d29f43$c278fd60$476af820$@augustcellars.com> 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: [COSE] Authentication tag X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 21:09:26 -0000 On Sat, Mar 18, 2017 at 09:08:09PM +0100, Samuel Erdtman wrote: > Thanks Jim and Ilari for the quick replies. > > So if I understand it correctly RFC 5116 defines AE and AEAD with the > requirement to bundle the tag with the ciphertext, so it would not be > allowed to put the tag in the COSE headers. Yes. > Section 10 Content Encryption Algorithms, gives a hint of where to find the > tag, 'normally' appended. Forgive me my ignorance, but does GCM have a more > normative requirement on the location of the tag in a ciphertext? RFC 5116 gives the tag location for AEAD_AES_{128,256}_GCM: It is appended. AEAD_CHACHA20_POLY1305 initially got it wrong, the document has errata that the tag is also appended. But there are RFC 5116-framework AEAD algorithms that don't append the tag. E.g AEAD_AES_SIV_CMAC_* prepends the equivalent of tag, not appends. > If GCM does not mandate the location of the tag in the ciphertext and we > cannot put it in a header attribute then I would like more explicit > language about where to find/put the tag. Funkily enough, COSE has AES-192-GCM, but there is no registered AEAD cipher for that. And then COSE has plenty of CCM ciphers, which probably don't have registed counterparts. Also, I didn't find any reference based on quick look that would say that the tags are definitely appended (but that's the only sane way). -Ilari From nobody Sat Mar 18 14:09:41 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDA4129444 for ; Sat, 18 Mar 2017 14:09:39 -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, HTML_MESSAGE=0.001, 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 x_v83KHzfXGA for ; Sat, 18 Mar 2017 14:09:33 -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 3BC53129442 for ; Sat, 18 Mar 2017 14:09:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0166_01D29FF1.40783480" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1489871372; h=from:subject:to:date:message-id; bh=V5zDegy6KmmyRUhTWfY9IDfsPPpwrYElDI1fvgWHzXE=; b=J9QWX7Fn1fbDLNY8LIcnr7+v5JYschsO2ySjWpeeWNmIZzAs+u7vUvT7yqmK6ZVVimf2wmvyy1r fkDl15LQ/2gQggMQZx8EdrypZ65k9XyrnEsBVpaW8mi0/6dTTtf7tkHMCxJxnvVl9aYiEatPXlhCo 7+fHjyYuY89H0sQzIJVrQhsaH7wgEs67ult0cHcplwXmSWPHw8sDhXgamk0YE3Ypcs3Es83lralHx xj10UQPPJJSyfwI6qI3ZK6hXA8/3woqXi/2wwpctKNMniRRL4pGN5esQkP06SfqGPT3JLG+ol3RyF WmH8pGeRmgowkNgf4W6/gfckokMJLA59GIPg== 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; Sat, 18 Mar 2017 14:09:31 -0700 Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 18 Mar 2017 14:06:56 -0700 From: Jim Schaad To: 'Samuel Erdtman' CC: 'cose' References: <00f701d29f43$c278fd60$476af820$@augustcellars.com> In-Reply-To: Date: Sat, 18 Mar 2017 14:09:23 -0700 Message-ID: <016501d2a02b$ecd2edd0$c678c970$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHJyY/ZCPv2uIyenJalNKBf3teWxAH2xgvQAiEsI4qhi/9SEA== X-Originating-IP: [173.8.216.38] Archived-At: Subject: Re: [COSE] Authentication tag X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 21:09:39 -0000 ------=_NextPart_000_0166_01D29FF1.40783480 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are two different schools of thought about where to put the = authentication tag. RFC 5116 was designed so that it is part of the = standard set of parameters rather than separate. Thus, for GCM, it is = included as part of the cipher text. For SIV mode it is the IV and = there is no extra authentication tag. =20 Other encodings have made the fields be separate, JOSE and CMS keep the = tag and the cipher text as separate items and, for some systems, you = then get the opposite world of needed to combined them when doing = decryption operation. The decision of where and how authentication = tags are placed is always going to be an encoding decision and not part = of the encryption algorithm. =20 The decision was made to combine them for COSE because it saved an = additional field, and thus one or more bytes are removed from the = encoding. This followed the guidance of trying for very short = encodings. =20 =20 I have filed an issue to remember this at the next revision. =20 Jim =20 =20 =20 From: Samuel Erdtman [mailto:samuel@erdtman.se]=20 Sent: Saturday, March 18, 2017 1:08 PM To: Jim Schaad ; ilariliusvaara@welho.com Cc: cose Subject: Re: Authentication tag =20 Thanks Jim and Ilari for the quick replies. So if I understand it correctly RFC 5116 defines AE and AEAD with the = requirement to bundle the tag with the ciphertext, so it would not be = allowed to put the tag in the COSE headers. Section 10 Content Encryption Algorithms, gives a hint of where to find = the tag, 'normally' appended. Forgive me my ignorance, but does GCM have = a more normative requirement on the location of the tag in a ciphertext? If GCM does not mandate the location of the tag in the ciphertext and we = cannot put it in a header attribute then I would like more explicit = language about where to find/put the tag. Once again thanks for the quick and enlightening reply. Cheers //Samuel =20 =20 On Fri, Mar 17, 2017 at 6:27 PM, Jim Schaad > wrote: >From Section 10: =20 COSE restricts the set of legal content encryption algorithms to those = that support authentication both of the content and additional data. The = encryption process will generate some type of authentication value, but = that value may be either explicit or implicit in terms of the algorithm = definition. For simplicity sake, the authentication code will normally = be defined as being appended to the cipher text stream. The encryption = functions are: =20 =20 From: Samuel Erdtman [mailto:samuel@erdtman.se = ]=20 Sent: Friday, March 17, 2017 9:50 AM To: cose >; Jim Schaad = > Subject: Authentication tag =20 Hi=20 I=C2=B4m working on a JavaScript implementation of the COSE msg = specification, currently working on the GCM encryption. In the nodejs crypto environment the authentication tag is set = separately i.e. a specific setAuthTag call. I looked into openssl and = could see that that was the case there too. In the examples provided with the COSE specification I could find out = that the auth tag is appends to the end of the ciphertext. I tried to find this described in the COSE specification but could not = find it. It might be described in some refereed specification but it was = not obvious to me at least. If it is not to late I would suggest that authentication tag is lifted = out from the ciphertext and into the unprotected header similar to IV. = Or that it is explicitly described that the authentication tag should be = appended to the ciphertext. Cheers Samuel Erdtman =20 =20 ------=_NextPart_000_0166_01D29FF1.40783480 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

There are = two different schools of thought about where to put the authentication = tag.=C2=A0 RFC 5116 was designed so that it is part of the standard set = of parameters rather than separate.=C2=A0 Thus, for GCM, it is included = as part of the cipher text.=C2=A0 For SIV mode it is the IV and there is = no extra authentication tag.

 

Other = encodings have made the fields be separate, JOSE and CMS keep the tag = and the cipher text as separate items and, for some systems, you then = get the opposite world of needed to combined them when doing decryption = operation. =C2=A0=C2=A0The decision of where and how authentication tags = are placed is always going to be an encoding decision and not part of = the encryption algorithm.

 

The = decision was made to combine them for COSE because it saved an = additional field, and thus one or more bytes are removed from the = encoding.=C2=A0 This followed the guidance of trying for very short = encodings.=C2=A0

 

I have filed = an issue to remember this at the next revision.

 

Jim

 

 

 

From:<= /b> = Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Saturday, = March 18, 2017 1:08 PM
To: Jim Schaad = <ietf@augustcellars.com>; ilariliusvaara@welho.com
Cc: = cose <cose@ietf.org>
Subject: Re: Authentication = tag

 

Thanks Jim and Ilari = for the quick replies.

So if I understand it correctly RFC 5116 = defines AE and AEAD with the requirement to bundle the tag with the = ciphertext, so it would not be allowed to put the tag in the COSE = headers.

Section 10 Content Encryption Algorithms, = gives a hint of where to find the tag, 'normally' appended. Forgive me = my ignorance, but does GCM have a more normative requirement on the = location of the tag in a ciphertext?

If GCM does not mandate = the location of the tag in the ciphertext and we cannot put it in a = header attribute then I would like more explicit language about where to = find/put the tag.

Once again thanks for the quick and = enlightening reply.

Cheers

//Samuel

 

 

On = Fri, Mar 17, 2017 at 6:27 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

From Section = 10:

 =

COSE = restricts the set of legal content encryption algorithms to those that = support authentication both of the content and additional data. The = encryption process will generate some type of authentication value, but = that value may be either explicit or implicit in terms of the algorithm = definition. For simplicity sake, the = authentication code will normally be defined as being appended to the = cipher text stream. The encryption functions = are:

 =

 =

From:<= /b> = Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Friday, March = 17, 2017 9:50 AM
To: cose <cose@ietf.org>; Jim Schaad <ietf@augustcellars.com>
Subject: = Authentication tag

 <= /o:p>

Hi =

I=C2=B4m working = on a JavaScript implementation of the COSE msg specification, currently = working on the GCM encryption.

In the nodejs crypto environment = the authentication tag is set separately i.e. a specific setAuthTag = call. I looked into openssl and could see that that was the case there = too.

In the examples = provided with the COSE specification I could find out that the auth tag = is appends to the end of the ciphertext.

I tried to find = this described in the COSE specification but could not find it. It might = be described in some refereed specification but it was not obvious to me = at least.

If it is not to = late I would suggest that authentication tag is lifted out from the = ciphertext and into the unprotected header similar to IV. Or that it is = explicitly described that the authentication tag should be appended to = the ciphertext.

Cheers<= /o:p>

Samuel = Erdtman

 <= /p>

 

------=_NextPart_000_0166_01D29FF1.40783480-- From nobody Mon Mar 20 12:58:07 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C759126C0F for ; Mon, 20 Mar 2017 12:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.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 Qn1MPR-Yihtc for ; Mon, 20 Mar 2017 12:57:52 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 AAFE113161E for ; Mon, 20 Mar 2017 12:57:50 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id a94so27822944oic.2 for ; Mon, 20 Mar 2017 12:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CCc0VwqSNBea00KSwYKXUuU4X8/D1k5MQp0D60mLXNA=; b=mZ+coyznY51jFlepbKQeSH93grIDB6NhjPdqlEIhMMebUPNb9qikKScVnsh1QQ21GA PD0dTdtiC7UZEGzKfsdf98QQkfUjgO4UbjvAnGi+INv55tiLhvnSWh/vMHs4cKh7txhM gELSL/bn8JSnHGtkDLWKevElggvt4UInAplV6dsl1sn8OiNFh/zGKnYPn3cyI/KDqg8X MrvEyXNrjIoR9MrPK+h8mja4S8zxulfg4Vgc3dAot03x2bJ8omhI6rCY1uNuAz4057VM yPkth2+9/GL3vIE2ZJEYNUHJ3E+Tzg0cHZVL9irNpu1xzf7KXoAvFqQl3+hZJSHUrSyE WKJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CCc0VwqSNBea00KSwYKXUuU4X8/D1k5MQp0D60mLXNA=; b=cgEojNlTTS6pP4jAjr2V2iwk1aqUQkDSRKQUojHeBoOf13HAITJUsEszkXR0IrulAm 45dUOXjzOi665Tog+0Xdg4Qka+GbDiuhrS1o9nJUq8Gx1wSBLMOv1VGtpP8GKbHpjXQO Go3wTXuYq3a5hB0oL2sI07EOYUjrVb/pVoD6M2GlgCitOhvQzx2P7LnP7Zk97AYnWMAq P3XNQYY00vvv2YUoa6V6+/TS0kocFaNxgS1XHbImXA20Vks5hQtTVqO8UxAvq9IgKICi Y3/ntqqMsC/jtK4IbLoqyrm8OLo3jMWcNlCAG6xuVWj570zq+4E7+W8R51jSELvBCeJP nUow== X-Gm-Message-State: AFeK/H2SDSD40WFVLTOeqpsCnUZZJUsUhytKhCZzazlH+EQvtG9dLBlRQ+BmW7BTTKNbpbj7F4AcWvBua22Z5g== X-Received: by 10.202.231.69 with SMTP id e66mr10417172oih.34.1490039870058; Mon, 20 Mar 2017 12:57:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.125.40 with HTTP; Mon, 20 Mar 2017 12:57:49 -0700 (PDT) In-Reply-To: <016501d2a02b$ecd2edd0$c678c970$@augustcellars.com> References: <00f701d29f43$c278fd60$476af820$@augustcellars.com> <016501d2a02b$ecd2edd0$c678c970$@augustcellars.com> From: Samuel Erdtman Date: Mon, 20 Mar 2017 20:57:49 +0100 Message-ID: To: Jim Schaad Cc: cose Content-Type: multipart/alternative; boundary=001a1141ad7c2808a6054b2ef16e Archived-At: Subject: Re: [COSE] Authentication tag X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 19:58:05 -0000 --001a1141ad7c2808a6054b2ef16e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks again! I think this will add some clarity for tormentors. //Samuel On Sat, Mar 18, 2017 at 10:09 PM, Jim Schaad wrote= : > There are two different schools of thought about where to put the > authentication tag. RFC 5116 was designed so that it is part of the > standard set of parameters rather than separate. Thus, for GCM, it is > included as part of the cipher text. For SIV mode it is the IV and there > is no extra authentication tag. > > > > Other encodings have made the fields be separate, JOSE and CMS keep the > tag and the cipher text as separate items and, for some systems, you then > get the opposite world of needed to combined them when doing decryption > operation. The decision of where and how authentication tags are placed > is always going to be an encoding decision and not part of the encryption > algorithm. > > > > The decision was made to combine them for COSE because it saved an > additional field, and thus one or more bytes are removed from the > encoding. This followed the guidance of trying for very short encodings. > > > > I have filed an issue to remember this at the next revision. > > > > Jim > > > > > > > > *From:* Samuel Erdtman [mailto:samuel@erdtman.se] > *Sent:* Saturday, March 18, 2017 1:08 PM > *To:* Jim Schaad ; ilariliusvaara@welho.com > *Cc:* cose > *Subject:* Re: Authentication tag > > > > Thanks Jim and Ilari for the quick replies. > > So if I understand it correctly RFC 5116 defines AE and AEAD with the > requirement to bundle the tag with the ciphertext, so it would not be > allowed to put the tag in the COSE headers. > > Section 10 Content Encryption Algorithms, gives a hint of where to find > the tag, 'normally' appended. Forgive me my ignorance, but does GCM have = a > more normative requirement on the location of the tag in a ciphertext? > > If GCM does not mandate the location of the tag in the ciphertext and we > cannot put it in a header attribute then I would like more explicit > language about where to find/put the tag. > > Once again thanks for the quick and enlightening reply. > > Cheers > > //Samuel > > > > > > On Fri, Mar 17, 2017 at 6:27 PM, Jim Schaad > wrote: > > From Section 10: > > > > COSE restricts the set of legal content encryption algorithms to those > that support authentication both of the content and additional data. The > encryption process will generate some type of authentication value, but > that value may be either explicit or implicit in terms of the algorithm > definition. For simplicity sake, the authentication code will normally be > defined as being appended to the cipher text stream. The encryption > functions are: > > > > > > *From:* Samuel Erdtman [mailto:samuel@erdtman.se] > *Sent:* Friday, March 17, 2017 9:50 AM > *To:* cose ; Jim Schaad > *Subject:* Authentication tag > > > > Hi > > I=C2=B4m working on a JavaScript implementation of the COSE msg specifica= tion, > currently working on the GCM encryption. > > In the nodejs crypto environment the authentication tag is set separately > i.e. a specific setAuthTag call. I looked into openssl and could see that > that was the case there too. > > In the examples provided with the COSE specification I could find out tha= t > the auth tag is appends to the end of the ciphertext. > > I tried to find this described in the COSE specification but could not > find it. It might be described in some refereed specification but it was > not obvious to me at least. > > If it is not to late I would suggest that authentication tag is lifted ou= t > from the ciphertext and into the unprotected header similar to IV. Or tha= t > it is explicitly described that the authentication tag should be appended > to the ciphertext. > > Cheers > > Samuel Erdtman > > > > > --001a1141ad7c2808a6054b2ef16e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks again!

I think this will add= some clarity for tormentors.

//Samuel

On Sat, Mar 18, 2017 at 10:09 P= M, Jim Schaad <ietf@augustcellars.com> wrote:

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= There are two different schools of thought about where to put the authentic= ation tag.=C2=A0 RFC 5116 was designed so that it is part of the standard s= et of parameters rather than separate.=C2=A0 Thus, for GCM, it is included = as part of the cipher text.=C2=A0 For SIV mode it is the IV and there is no= extra authentication tag.

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= =C2=A0

Other encodings have= made the fields be separate, JOSE and CMS keep the tag and the cipher text= as separate items and, for some systems, you then get the opposite world o= f needed to combined them when doing decryption operation. =C2=A0=C2=A0The = decision of where and how authentication tags are placed is always going to= be an encoding decision and not part of the encryption algorithm.

=C2=A0

The decision was made to combine them for COSE because= it saved an additional field, and thus one or more bytes are removed from = the encoding.=C2=A0 This followed the guidance of trying for very short enc= odings.=C2=A0

=C2= =A0

I have filed an issue to remem= ber this at the next revision.

=C2=A0

Jim

=C2=A0

=C2=A0

<= /u>=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= From: Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Saturday, Marc= h 18, 2017 1:08 PM
To: Jim Schaad <ietf@augustcellars.com>; ilariliusvaara@welho.co= m
Cc: cose <cose@ietf.org>
Subject: Re: Authentication tag=

=C2=A0

Thanks Jim and Ilari for the quick replies.

So if I un= derstand it correctly RFC 5116 defines AE and AEAD with the requirement to = bundle the tag with the ciphertext, so it would not be allowed to put the t= ag in the COSE headers.

Section 10 Content Encryption Algorithms, gives a= hint of where to find the tag, 'normally' appended. Forgive me my = ignorance, but does GCM have a more normative requirement on the location o= f the tag in a ciphertext?

If GCM does not mandate the location of th= e tag in the ciphertext and we cannot put it in a header attribute then I w= ould like more explicit language about where to find/put the tag.=

On= ce again thanks for the quick and enlightening reply.

Cheers

//Samuel

=C2=A0

=C2=A0

On Fri, Mar 17, 2017 at 6:27 PM, Jim Schaad <ietf@augustcellars.com> wrote:

From Section 10:

=C2=A0

COSE= restricts the set of legal content encryption algorithms to those that sup= port authentication both of the content and additional data. The encryption= process will generate some type of authentication value, but that value ma= y be either explicit or implicit in terms of the algorithm definition. For simplicity sake, the authentication code will nor= mally be defined as being appended to the cipher text stream. The en= cryption functions are:

=C2=A0

=C2=A0

From: Samuel E= rdtman [mailto:samue= l@erdtman.se]
Sent: Friday, March 17, 2017 9:50 AM
To:= cose <cose@ietf.= org>; Jim Schaad <ietf@augustcellars.com>
Subject: Authenticati= on tag

=C2=A0

Hi

I=C2=B4m working on a JavaScr= ipt implementation of the COSE msg specification, currently working on the = GCM encryption.

In the nodejs crypto environment the authentication = tag is set separately i.e. a specific setAuthTag call. I looked into openss= l and could see that that was the case there too.

In the examples provide= d with the COSE specification I could find out that the auth tag is appends= to the end of the ciphertext.

I tried to find this described in the COSE= specification but could not find it. It might be described in some referee= d specification but it was not obvious to me at least.

If it is not to la= te I would suggest that authentication tag is lifted out from the ciphertex= t and into the unprotected header similar to IV. Or that it is explicitly d= escribed that the authentication tag should be appended to the ciphertext.<= u>

Cheers

Samuel Erdtman

=C2=A0<= /u>

<= /div>

=C2=A0


--001a1141ad7c2808a6054b2ef16e-- From nobody Mon Mar 20 12:58:34 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEB5131677 for ; Mon, 20 Mar 2017 12:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.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 LsJ17Owzahf0 for ; Mon, 20 Mar 2017 12:58:26 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 2203313166B for ; Mon, 20 Mar 2017 12:58:12 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id x37so139674916ota.2 for ; Mon, 20 Mar 2017 12:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nTRVhOm97NkcZoPi/oPcvkJSoSMnshFcKlcJ8gKQVPY=; b=ibqpPn4dqrDIhO4mWmGWyeARC74ZOzM77qKYtPUGxCV+NPOEAuCjuAUR2iY2LadMbn HtSbTg6WfP+4PKsj1lpTPB9wVAdon+FHTAC7StKFOm1dLyFZkc5dOnr1Y0guOWW/mIO/ fziAyUge5ltMtIFo9W+cRmGQ1Ml9BcntLijilmi3cpm+TD+Vgcj98Q9UMjzqH5vIH1ZI UmsGWJd+uVkKPpY2+5dH5tBl/rMGBa1Fjxu77KmejMxsSCsKZbmR0cE8caQSIzEF9Ri8 Dp50wieBCqAw3XB/saLRSvGnOab5THKXaxRrIIVRn2fct/Xt0Gmq3EAcnz1oJ6PwSomw jeNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nTRVhOm97NkcZoPi/oPcvkJSoSMnshFcKlcJ8gKQVPY=; b=RneRRPjD4zBS20lgk6IH1ZvOPNZpbAmx0RSy0VD6Nj+2fKrR/kPOUIY/h/fE5t5qh+ FfJbob0jvOXi82AoodZHdDL5ZmQ7j6wFpq1Fa/GcENSdaPaSql2/vD36r/HBHlrxIAgt a0vzZCPOweBRAlBR0nbj6IwV3B+UcYweEohS3CH+y8pdYBsPce53ZlKNPVus1CV/xWgw gc2IRZvor1mSpP3/S7Tyr3EajjYq55fb/UV5BowRYAdy7bjOthPWaqCDM48ZA5P0eIxT wc6K04B4MENKjXq/Mu9Gag5bbqh9V1pj5IEJlAJgO69AWMDZR1z73bkTb9nkpQmHJ9/O cmaQ== X-Gm-Message-State: AFeK/H0FuOynyL6hwDtUpVeSyYTbaRh1UWkS+VMD6+USuglco+DDQZQVvacgyJt62Kqr9d+SccBTV8atdadExQ== X-Received: by 10.157.27.164 with SMTP id z33mr17404025otd.164.1490039891458; Mon, 20 Mar 2017 12:58:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.125.40 with HTTP; Mon, 20 Mar 2017 12:58:10 -0700 (PDT) In-Reply-To: References: <00f701d29f43$c278fd60$476af820$@augustcellars.com> <016501d2a02b$ecd2edd0$c678c970$@augustcellars.com> From: Samuel Erdtman Date: Mon, 20 Mar 2017 20:58:10 +0100 Message-ID: To: Jim Schaad Cc: cose Content-Type: multipart/alternative; boundary=001a1141a8346e8fdb054b2ef2e6 Archived-At: Subject: Re: [COSE] Authentication tag X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 19:58:33 -0000 --001a1141a8346e8fdb054b2ef2e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable *implementers On Mon, Mar 20, 2017 at 8:57 PM, Samuel Erdtman wrote: > Thanks again! > > I think this will add some clarity for tormentors. > > //Samuel > > On Sat, Mar 18, 2017 at 10:09 PM, Jim Schaad > wrote: > >> There are two different schools of thought about where to put the >> authentication tag. RFC 5116 was designed so that it is part of the >> standard set of parameters rather than separate. Thus, for GCM, it is >> included as part of the cipher text. For SIV mode it is the IV and ther= e >> is no extra authentication tag. >> >> >> >> Other encodings have made the fields be separate, JOSE and CMS keep the >> tag and the cipher text as separate items and, for some systems, you the= n >> get the opposite world of needed to combined them when doing decryption >> operation. The decision of where and how authentication tags are place= d >> is always going to be an encoding decision and not part of the encryptio= n >> algorithm. >> >> >> >> The decision was made to combine them for COSE because it saved an >> additional field, and thus one or more bytes are removed from the >> encoding. This followed the guidance of trying for very short encodings= . >> >> >> >> I have filed an issue to remember this at the next revision. >> >> >> >> Jim >> >> >> >> >> >> >> >> *From:* Samuel Erdtman [mailto:samuel@erdtman.se] >> *Sent:* Saturday, March 18, 2017 1:08 PM >> *To:* Jim Schaad ; ilariliusvaara@welho.com >> *Cc:* cose >> *Subject:* Re: Authentication tag >> >> >> >> Thanks Jim and Ilari for the quick replies. >> >> So if I understand it correctly RFC 5116 defines AE and AEAD with the >> requirement to bundle the tag with the ciphertext, so it would not be >> allowed to put the tag in the COSE headers. >> >> Section 10 Content Encryption Algorithms, gives a hint of where to find >> the tag, 'normally' appended. Forgive me my ignorance, but does GCM have= a >> more normative requirement on the location of the tag in a ciphertext? >> >> If GCM does not mandate the location of the tag in the ciphertext and we >> cannot put it in a header attribute then I would like more explicit >> language about where to find/put the tag. >> >> Once again thanks for the quick and enlightening reply. >> >> Cheers >> >> //Samuel >> >> >> >> >> >> On Fri, Mar 17, 2017 at 6:27 PM, Jim Schaad >> wrote: >> >> From Section 10: >> >> >> >> COSE restricts the set of legal content encryption algorithms to those >> that support authentication both of the content and additional data. The >> encryption process will generate some type of authentication value, but >> that value may be either explicit or implicit in terms of the algorithm >> definition. For simplicity sake, the authentication code will normally >> be defined as being appended to the cipher text stream. The encryption >> functions are: >> >> >> >> >> >> *From:* Samuel Erdtman [mailto:samuel@erdtman.se] >> *Sent:* Friday, March 17, 2017 9:50 AM >> *To:* cose ; Jim Schaad >> *Subject:* Authentication tag >> >> >> >> Hi >> >> I=C2=B4m working on a JavaScript implementation of the COSE msg specific= ation, >> currently working on the GCM encryption. >> >> In the nodejs crypto environment the authentication tag is set separatel= y >> i.e. a specific setAuthTag call. I looked into openssl and could see tha= t >> that was the case there too. >> >> In the examples provided with the COSE specification I could find out >> that the auth tag is appends to the end of the ciphertext. >> >> I tried to find this described in the COSE specification but could not >> find it. It might be described in some refereed specification but it was >> not obvious to me at least. >> >> If it is not to late I would suggest that authentication tag is lifted >> out from the ciphertext and into the unprotected header similar to IV. O= r >> that it is explicitly described that the authentication tag should be >> appended to the ciphertext. >> >> Cheers >> >> Samuel Erdtman >> >> >> >> >> > > --001a1141a8346e8fdb054b2ef2e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
*implementers

On Mon, Mar 20, 2017 at 8:57 PM, Samuel Erdtman <s= amuel@erdtman.se> wrote:
Thanks again!

I think this will add s= ome clarity for tormentors.<= br>
/= /Samuel

On Sat, Mar 18, 2017 = at 10:09 PM, Jim Schaad <ietf@augustcellars.com> wrote:=

There are two different schools of thought = about where to put the authentication tag.=C2=A0 RFC 5116 was designed so t= hat it is part of the standard set of parameters rather than separate.=C2= =A0 Thus, for GCM, it is included as part of the cipher text.=C2=A0 For SIV= mode it is the IV and there is no extra authentication tag.<= /span>

=C2=A0

Other encodings have made the fields be separate, JOSE and = CMS keep the tag and the cipher text as separate items and, for some system= s, you then get the opposite world of needed to combined them when doing de= cryption operation. =C2=A0=C2=A0The decision of where and how authenticatio= n tags are placed is always going to be an encoding decision and not part o= f the encryption algorithm.

= =C2=A0

The decision was m= ade to combine them for COSE because it saved an additional field, and thus= one or more bytes are removed from the encoding.=C2=A0 This followed the g= uidance of trying for very short encodings.=C2=A0

=

=C2=A0

I have filed an issue to remember this at the next revision.<= /u>

=C2=A0

Jim

=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /u>

Thanks Jim and Ilari for the quick replies.

So if I understand it correc= tly RFC 5116 defines AE and AEAD with the requirement to bundle the tag wit= h the ciphertext, so it would not be allowed to put the tag in the COSE hea= ders.

Section 10 Content Encryption Algorithms, gives a hint of where to = find the tag, 'normally' appended. Forgive me my ignorance, but doe= s GCM have a more normative requirement on the location of the tag in a cip= hertext?

If GCM does not mandate the location of the tag in the ciphe= rtext and we cannot put it in a header attribute then I would like more exp= licit language about where to find/put the tag.

Once again thanks fo= r the quick and enlightening reply.

Cheers

//Sam= uel

=C2=A0

=C2=A0

On Fri, Mar 17, 2= 017 at 6:27 PM, Jim Schaad <ietf@augustcellars.com> wrote:

From Section 10:

=C2= =A0

COSE restricts the set o= f legal content encryption algorithms to those that support authentication = both of the content and additional data. The encryption process will genera= te some type of authentication value, but that value may be either explicit= or implicit in terms of the algorithm definition. For simplicity sake, the authentication code will normally be defined as = being appended to the cipher text stream. The encryption functions a= re:

=C2=A0

=C2=A0

From: Samuel Erdtman [mailto:samuel@erdtman.se] Sent: Friday, March 17, 2017 9:50 AM
To: cose <cose@ietf.org>; Jim Sch= aad <ietf@au= gustcellars.com>
Subject: Authentication tag=

=C2=A0

Hi

I=C2=B4m working on a JavaScript implementation o= f the COSE msg specification, currently working on the GCM encryption.
<= br>In the nodejs crypto environment the authentication tag is set separatel= y i.e. a specific setAuthTag call. I looked into openssl and could see that= that was the case there too.

In the examples provided with the COSE spec= ification I could find out that the auth tag is appends to the end of the c= iphertext.

I tried to find this described in the COSE specification but c= ould not find it. It might be described in some refereed specification but = it was not obvious to me at least.

If it is not to late I would suggest t= hat authentication tag is lifted out from the ciphertext and into the unpro= tected header similar to IV. Or that it is explicitly described that the au= thentication tag should be appended to the ciphertext.

Cheers

Samuel Erdtman

=C2=A0

=C2=A0



--001a1141a8346e8fdb054b2ef2e6-- From nobody Mon Mar 20 13:10:04 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8285C12762F for ; Mon, 20 Mar 2017 13:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0SamIc24Gjp9 for ; Mon, 20 Mar 2017 13:10:01 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 178EF1274D2 for ; Mon, 20 Mar 2017 13:10:00 -0700 (PDT) X-AuditID: 1209190d-5ffff70000001c9e-0f-58d037164e64 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 27.31.07326.61730D85; Mon, 20 Mar 2017 16:09:59 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v2KK9wil029615; Mon, 20 Mar 2017 16:09:58 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v2KK9sEn005856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Mar 2017 16:09:56 -0400 From: Justin Richer Message-Id: <44DF8A98-2191-4E9F-811F-E000D7FB7092@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_54D4904F-DDB1-4C7C-AA1F-9AEA4A849024" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 20 Mar 2017 16:09:54 -0400 In-Reply-To: Cc: Jim Schaad , cose To: Samuel Erdtman References: <00f701d29f43$c278fd60$476af820$@augustcellars.com> <016501d2a02b$ecd2edd0$c678c970$@augustcellars.com> X-Mailer: Apple Mail (2.3259) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixG6nritufiHC4PhWK4tpW6eyWqye/p3N 4v/SU0wOzB4b50xn83jxbw+jx5IlP5kCmKO4bFJSczLLUov07RK4Mi43bGcpWDmFsaLj8gK2 BsY9jYxdjJwcEgImEi/Xz2MFsYUE2pgkXt127GLkArI3MkocWz+HEcJ5yCSx5cgCsCo2AVWJ 6WtamEBsXgEriYbJF8BsZoEkifsNV1gg4voSs89cArOFBdQkDrQfAdvGAtTb3fWPGcTmFAiU mPPjGDNEr63EhB8fwWwRoPq7Bx+xQiyeyCzx7fsbNohTZSXe/lrCPIGRfxaSfbOQ7IOIa0ss W/iaGcLWlNjfvRyLuIZE57eJrAsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbpGunlZpbopaaU bmIEhTynJO8Oxn93vQ4xCnAwKvHwrrhyPkKINbGsuDL3EKMkB5OSKO/T20AhvqT8lMqMxOKM +KLSnNTiQ4wSHMxKIrwfFS9ECPGmJFZWpRblw6SkOViUxHnFNRojhATSE0tSs1NTC1KLYLIy HBxKEryXTYEaBYtS01Mr0jJzShDSTBycIMN5gIa/A6nhLS5IzC3OTIfIn2JUlBLn3QaSEABJ ZJTmwfWCUlLC28OmrxjFgV4R5l0GUsUDTGdw3a+ABjMBDV524wzI4JJEhJRUA+OSfVXKXPFX tGKVjqs35k7ftP8E+1xWrpeBzZ15a2x07Db3x308rB9pXlrH/knkXYnAW5ODu+UMp6kInmjb G+CSf37Whyj/qwrMPmncf9fVbynLDOI/93n3NL2agrwf5oIndVqM3jw8u2R2Vcr37Q/CbSIl zubaz+vmU1IUCLPaeY3nwpOVNUosxRmJhlrMRcWJAEzzBUYkAwAA Archived-At: Subject: Re: [COSE] Authentication tag X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 20:10:03 -0000 --Apple-Mail=_54D4904F-DDB1-4C7C-AA1F-9AEA4A849024 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Well you weren=E2=80=99t necessarily *wrong* the first time. =E2=80=94 Justin, not as chair > On Mar 20, 2017, at 3:58 PM, Samuel Erdtman wrote: >=20 > *implementers=20 >=20 > On Mon, Mar 20, 2017 at 8:57 PM, Samuel Erdtman > wrote: > Thanks again! >=20 > I think this will add some clarity for tormentors. >=20 > //Samuel >=20 > On Sat, Mar 18, 2017 at 10:09 PM, Jim Schaad > wrote: > There are two different schools of thought about where to put the = authentication tag. RFC 5116 was designed so that it is part of the = standard set of parameters rather than separate. Thus, for GCM, it is = included as part of the cipher text. For SIV mode it is the IV and = there is no extra authentication tag. >=20 > =20 >=20 > Other encodings have made the fields be separate, JOSE and CMS keep = the tag and the cipher text as separate items and, for some systems, you = then get the opposite world of needed to combined them when doing = decryption operation. The decision of where and how authentication = tags are placed is always going to be an encoding decision and not part = of the encryption algorithm. >=20 > =20 >=20 > The decision was made to combine them for COSE because it saved an = additional field, and thus one or more bytes are removed from the = encoding. This followed the guidance of trying for very short = encodings.=20 >=20 > =20 >=20 > I have filed an issue to remember this at the next revision. >=20 > =20 >=20 > Jim >=20 > =20 >=20 > =20 >=20 > =20 >=20 > From: Samuel Erdtman [mailto:samuel@erdtman.se = ]=20 > Sent: Saturday, March 18, 2017 1:08 PM > To: Jim Schaad >; ilariliusvaara@welho.com = > Cc: cose > > Subject: Re: Authentication tag >=20 > =20 >=20 > Thanks Jim and Ilari for the quick replies. >=20 > So if I understand it correctly RFC 5116 defines AE and AEAD with the = requirement to bundle the tag with the ciphertext, so it would not be = allowed to put the tag in the COSE headers. >=20 > Section 10 Content Encryption Algorithms, gives a hint of where to = find the tag, 'normally' appended. Forgive me my ignorance, but does GCM = have a more normative requirement on the location of the tag in a = ciphertext? >=20 > If GCM does not mandate the location of the tag in the ciphertext and = we cannot put it in a header attribute then I would like more explicit = language about where to find/put the tag. >=20 > Once again thanks for the quick and enlightening reply. >=20 > Cheers >=20 > //Samuel >=20 > =20 >=20 > =20 >=20 > On Fri, Mar 17, 2017 at 6:27 PM, Jim Schaad > wrote: >=20 > =46rom Section 10: >=20 > =20 >=20 > COSE restricts the set of legal content encryption algorithms to those = that support authentication both of the content and additional data. The = encryption process will generate some type of authentication value, but = that value may be either explicit or implicit in terms of the algorithm = definition. For simplicity sake, the authentication code will normally = be defined as being appended to the cipher text stream. The encryption = functions are: >=20 > =20 >=20 > =20 >=20 > From: Samuel Erdtman [mailto:samuel@erdtman.se = ]=20 > Sent: Friday, March 17, 2017 9:50 AM > To: cose >; Jim Schaad = > > Subject: Authentication tag >=20 > =20 >=20 > Hi >=20 > I=C2=B4m working on a JavaScript implementation of the COSE msg = specification, currently working on the GCM encryption. >=20 > In the nodejs crypto environment the authentication tag is set = separately i.e. a specific setAuthTag call. I looked into openssl and = could see that that was the case there too. >=20 > In the examples provided with the COSE specification I could find out = that the auth tag is appends to the end of the ciphertext. >=20 > I tried to find this described in the COSE specification but could not = find it. It might be described in some refereed specification but it was = not obvious to me at least. >=20 > If it is not to late I would suggest that authentication tag is lifted = out from the ciphertext and into the unprotected header similar to IV. = Or that it is explicitly described that the authentication tag should be = appended to the ciphertext. >=20 > Cheers >=20 > Samuel Erdtman >=20 > =20 >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_54D4904F-DDB1-4C7C-AA1F-9AEA4A849024 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Well you weren=E2=80=99t necessarily *wrong* the first = time.

 =E2=80=94 = Justin, not as chair


On Mar 20, 2017, at 3:58 PM, Samuel Erdtman <samuel@erdtman.se> = wrote:

*implementers

On Mon, Mar 20, 2017 at 8:57 PM, Samuel Erdtman = <samuel@erdtman.se> wrote:
Thanks again!
I think this will add some clarity for = tormentors.

//Samuel

On Sat, Mar 18, 2017 at 10:09 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

There are two different schools of thought about where to put = the authentication tag.  RFC 5116 was designed so that it is part = of the standard set of parameters rather than separate.  Thus, for = GCM, it is included as part of the cipher text.  For SIV mode it is = the IV and there is no extra authentication tag.

 

Other encodings have made the fields be separate, JOSE and = CMS keep the tag and the cipher text as separate items and, for some = systems, you then get the opposite world of needed to combined them when = doing decryption operation.   The decision of where and how = authentication tags are placed is always going to be an encoding = decision and not part of the encryption algorithm.

 

The decision was made to combine them for COSE because it = saved an additional field, and thus one or more bytes are removed from = the encoding.  This followed the guidance of trying for very short = encodings. 

 

I have filed an issue to remember this at the next = revision.

 

Jim

 

 

 

From: Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Saturday, March 18, 2017 1:08 PM
To: Jim Schaad <ietf@augustcellars.com>; ilariliusvaara@welho.com
Cc: cose <cose@ietf.org>
Subject: Re: Authentication tag

 

Thanks Jim and Ilari for the quick = replies.

So if I understand it = correctly RFC 5116 defines AE and AEAD with the requirement to bundle = the tag with the ciphertext, so it would not be allowed to put the tag = in the COSE headers.

Section 10 Content = Encryption Algorithms, gives a hint of where to find the tag, 'normally' = appended. Forgive me my ignorance, but does GCM have a more normative = requirement on the location of the tag in a ciphertext?

If GCM does not = mandate the location of the tag in the ciphertext and we cannot put it = in a header attribute then I would like more explicit language about = where to find/put the tag.

Once again thanks for the quick and = enlightening reply.

Cheers

//Samuel

 

 

On Fri, Mar = 17, 2017 at 6:27 PM, Jim Schaad <ietf@augustcellars.com> wrote:

=46rom Section 10:

 

COSE restricts the set of legal content encryption = algorithms to those that support authentication both of the content and = additional data. The encryption process will generate some type of = authentication value, but that value may be either explicit or implicit = in terms of the algorithm definition. For simplicity sake, the authentication code will normally be = defined as being appended to the cipher text stream. The = encryption functions are:

 

 

From: Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Friday, March 17, 2017 9:50 AM
To: cose <cose@ietf.org>; Jim Schaad <ietf@augustcellars.com>
Subject: Authentication tag

 

Hi

I=C2=B4m working on a JavaScript = implementation of the COSE msg specification, currently working on the = GCM encryption.

In the nodejs crypto = environment the authentication tag is set separately i.e. a specific = setAuthTag call. I looked into openssl and could see that that was the = case there too.

In the examples = provided with the COSE specification I could find out that the auth tag = is appends to the end of the ciphertext.

I tried to find this described in the = COSE specification but could not find it. It might be described in some = refereed specification but it was not obvious to me at least.

If it is not to late I would suggest that = authentication tag is lifted out from the ciphertext and into the = unprotected header similar to IV. Or that it is explicitly described = that the authentication tag should be appended to the ciphertext.

Cheers

Samuel = Erdtman

 

<= /div>

 

=

_______________________________________________
COSE = mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

= --Apple-Mail=_54D4904F-DDB1-4C7C-AA1F-9AEA4A849024-- From nobody Tue Mar 21 06:06:46 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EB8129865 for ; Tue, 21 Mar 2017 06:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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 jXW4Do-kWXhj for ; Tue, 21 Mar 2017 06:06:41 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 97022129484 for ; Tue, 21 Mar 2017 06:06:41 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id y76so134035969qkb.0 for ; Tue, 21 Mar 2017 06:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=H506FpoTXxRsJ/mFiChXhwxpoXLMkTDXg0m4hpxnR9E=; b=uydSDHF8sOiK16EyRGhCDnk0PHZx5vXxEvjzwtWu+pmaiu/V/DSDusLKycW6AxN5cb CfXIafnoTwB0Nu+9NorxHu7NVVXIuPOwTdIxVyumQmUN77VAlAKopyboObN4rVutHVUx bwRlvJef83CK6QX/Q3JEwmU9bTWkLGKuNzn4nea6CtDrfzW25E17ogCxOQhe6m1uMf1D pysa4uHN3LsGlN5uu2lPHHxdZiJwdOiNguBWubgibujftrkimOkBaBJUNlYoaDB0I5eo Pf4TkyRgiAeAkJusLKtrw8I5ERK2/VLtEOv55tUEpjfkQu6oXKAvyW7b/pzhTzVVIjQk yI8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=H506FpoTXxRsJ/mFiChXhwxpoXLMkTDXg0m4hpxnR9E=; b=a0rSGbgCvu9IyAHCjVHqiSlAYG72ni6++D+gP61rnP33p/IfH5w/bTsEzvrxGKFLmf RNLsQCmJtLfRLLNjl+8TgfU6SB2pwKRN3Fk7nnGi9eWaxg6aBEdox3AWN2vNnDJ2ZScl QrKIOfpG91BGrswYQZvwnkxrPR9C6QUTXNl8IZa4kRI9dc2KODVbuc2atUYV3XmlINOp 5Tjd42OfbVEykZj5PybY7Oa0h29jZ4k4uq3/TEBotFcYRBZ1FOQfVocN17a9vQgvyypZ bo5TQJTJKvurSApbJgf/y/ve/pz/2iKXFX2O/z49UR/rc9jfpqS5GO11z0IwfJum+Wbv eZxA== X-Gm-Message-State: AFeK/H02c7hKiLWWbkPBjGndksiIs+lbO076o4sbKGI/T79eifTSurHpfoOLJQCrkO3K//Bb4RUwb4ist3pHDg== X-Received: by 10.55.217.72 with SMTP id u69mr18785026qki.20.1490101600626; Tue, 21 Mar 2017 06:06:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.36.21 with HTTP; Tue, 21 Mar 2017 06:06:20 -0700 (PDT) In-Reply-To: <44DF8A98-2191-4E9F-811F-E000D7FB7092@mit.edu> References: <00f701d29f43$c278fd60$476af820$@augustcellars.com> <016501d2a02b$ecd2edd0$c678c970$@augustcellars.com> <44DF8A98-2191-4E9F-811F-E000D7FB7092@mit.edu> From: Renzo Navas Date: Tue, 21 Mar 2017 14:06:20 +0100 Message-ID: To: Justin Richer Cc: Samuel Erdtman , Jim Schaad , cose Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [COSE] Authentication tag X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 13:06:44 -0000 Hi COSE WG! Just to add weight to the request of clarifying this on the COSE document (if its already possible), I faced the same problem as Samuel (up until this morning), I am implementing decryption of Encrypt0 cose objects; testing with a decryption of a COSE Enc0 object AES-CCM-16-64-128 generated with https://github.com/cose-wg/COSE-JAVA And the clearer text I found was on "1.1. Design changes from JOSE" : " * Combine the authentication tag for encryption algorithms with the cipher text." Now Jim pointed section 10 that also clarifies that. I think that putting some text on section 5.2/5.3/5.4 will be really helpful for implementers. Then reading only Section 5.2-5.4 will clarify almost everything to needed to decrypt/encrypt an Encrypt0 object. For instance on Section 5.3 (how to encrypt) "5. .. Place the returned cipher text [with the appended returned authentication tag] into the 'ciphertext' field of the structure." The decryption instruction will need a little bit more phrasing to explain; but once at least the encryption is clear, will be easily understandable for anyone reading the doc. Thank you for the work Jim and the nice already working implementations! Renzo On Mon, Mar 20, 2017 at 9:09 PM, Justin Richer wrote: > Well you weren=E2=80=99t necessarily *wrong* the first time. > > =E2=80=94 Justin, not as chair > > > On Mar 20, 2017, at 3:58 PM, Samuel Erdtman wrote: > > *implementers > > On Mon, Mar 20, 2017 at 8:57 PM, Samuel Erdtman wrote= : >> >> Thanks again! >> >> I think this will add some clarity for tormentors. >> >> //Samuel >> >> On Sat, Mar 18, 2017 at 10:09 PM, Jim Schaad >> wrote: >>> >>> There are two different schools of thought about where to put the >>> authentication tag. RFC 5116 was designed so that it is part of the >>> standard set of parameters rather than separate. Thus, for GCM, it is >>> included as part of the cipher text. For SIV mode it is the IV and the= re is >>> no extra authentication tag. >>> >>> >>> >>> Other encodings have made the fields be separate, JOSE and CMS keep the >>> tag and the cipher text as separate items and, for some systems, you th= en >>> get the opposite world of needed to combined them when doing decryption >>> operation. The decision of where and how authentication tags are plac= ed is >>> always going to be an encoding decision and not part of the encryption >>> algorithm. >>> >>> >>> >>> The decision was made to combine them for COSE because it saved an >>> additional field, and thus one or more bytes are removed from the encod= ing. >>> This followed the guidance of trying for very short encodings. >>> >>> >>> >>> I have filed an issue to remember this at the next revision. >>> >>> >>> >>> Jim >>> >>> >>> >>> >>> >>> >>> >>> From: Samuel Erdtman [mailto:samuel@erdtman.se] >>> Sent: Saturday, March 18, 2017 1:08 PM >>> To: Jim Schaad ; ilariliusvaara@welho.com >>> Cc: cose >>> Subject: Re: Authentication tag >>> >>> >>> >>> Thanks Jim and Ilari for the quick replies. >>> >>> So if I understand it correctly RFC 5116 defines AE and AEAD with the >>> requirement to bundle the tag with the ciphertext, so it would not be >>> allowed to put the tag in the COSE headers. >>> >>> Section 10 Content Encryption Algorithms, gives a hint of where to find >>> the tag, 'normally' appended. Forgive me my ignorance, but does GCM hav= e a >>> more normative requirement on the location of the tag in a ciphertext? >>> >>> If GCM does not mandate the location of the tag in the ciphertext and w= e >>> cannot put it in a header attribute then I would like more explicit lan= guage >>> about where to find/put the tag. >>> >>> Once again thanks for the quick and enlightening reply. >>> >>> Cheers >>> >>> //Samuel >>> >>> >>> >>> >>> >>> On Fri, Mar 17, 2017 at 6:27 PM, Jim Schaad >>> wrote: >>> >>> From Section 10: >>> >>> >>> >>> COSE restricts the set of legal content encryption algorithms to those >>> that support authentication both of the content and additional data. Th= e >>> encryption process will generate some type of authentication value, but= that >>> value may be either explicit or implicit in terms of the algorithm >>> definition. For simplicity sake, the authentication code will normally = be >>> defined as being appended to the cipher text stream. The encryption >>> functions are: >>> >>> >>> >>> >>> >>> From: Samuel Erdtman [mailto:samuel@erdtman.se] >>> Sent: Friday, March 17, 2017 9:50 AM >>> To: cose ; Jim Schaad >>> Subject: Authentication tag >>> >>> >>> >>> Hi >>> >>> I=C2=B4m working on a JavaScript implementation of the COSE msg specifi= cation, >>> currently working on the GCM encryption. >>> >>> In the nodejs crypto environment the authentication tag is set separate= ly >>> i.e. a specific setAuthTag call. I looked into openssl and could see th= at >>> that was the case there too. >>> >>> In the examples provided with the COSE specification I could find out >>> that the auth tag is appends to the end of the ciphertext. >>> >>> I tried to find this described in the COSE specification but could not >>> find it. It might be described in some refereed specification but it wa= s not >>> obvious to me at least. >>> >>> If it is not to late I would suggest that authentication tag is lifted >>> out from the ciphertext and into the unprotected header similar to IV. = Or >>> that it is explicitly described that the authentication tag should be >>> appended to the ciphertext. >>> >>> Cheers >>> >>> Samuel Erdtman >>> >>> >>> >>> >> >> > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose >