From nobody Fri Jun 3 17:51:52 2016 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 2131712D19F for ; Fri, 3 Jun 2016 17:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 K_HQXGeYjnUv for ; Fri, 3 Jun 2016 17:51:48 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 B174812B05D for ; Fri, 3 Jun 2016 17:51:46 -0700 (PDT) X-AuditID: 12074424-c9bff70000000add-9d-57522620dcaa Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 18.A6.02781.02622575; Fri, 3 Jun 2016 20:51:45 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u540phAQ025222 for ; Fri, 3 Jun 2016 20:51:44 -0400 Received: from [192.168.128.57] (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 u540pfF9001817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 3 Jun 2016 20:51:43 -0400 To: "cose@ietf.org" From: Justin Richer Message-ID: Date: Fri, 3 Jun 2016 20:51:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsUixCmqrKuoFhRu0LFU2WLa1qmsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK2HXWo2AzW8XNQ61sDYxdrF2MnBwSAiYSi1t7GEFsIYE2Jon9 E1S7GLmA7COMEhOvt7FAOO+ZJFb8mgJWJSKgLDHpWDNYN5uAqsT0NS1MILawgIzE3Nt3WUBs XgErib1vNoPVsAioSJxvOcYMYosKxEg03j7MDlEjKHFy5hOwemYBM4l5mx8yQ9jyEtvfzmGe wMg7C0nZLCRls5CULWBkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRrrpebWaKXmlK6iREUSuwu KjsYu3u8DzEKcDAq8fAWPAsMF2JNLCuuzD3EKMnBpCTKu/cOUIgvKT+lMiOxOCO+qDQntfgQ owQHs5II7xXloHAh3pTEyqrUonyYlDQHi5I4LyMDA4OQQHpiSWp2ampBahFMVoODQ+DVzSsr GaVY8vLzUpUkeMVVgYYIFqWmp1akZeaUIJQycXCCLOIBWqQLUsNbXJCYW5yZDpE/xajLseDH 7bVMQmCDpIBWghQJgBRllObBzQGlhoS3h01fMYoDvSjMqw9SxQNMK3CTXgEtYQJaUvDIH2RJ SSJCSqqB0c6X98H+HqdVFycESBUxaLZKz3/X1dTwNH5yYdbNE/GPFAv23Zho9jv06ZKDC0RE ZR23J+ddl+TikxCJvZez5kbskuNyrrc/yesvZWqtcmDhld/a8GybqasdA09dmuznUNH2shVz 7h/aVyoQp9l5LbxL81qySIDGzab74osyVZiY+zn/dlxQYinOSDTUYi4qTgQAVfS6GugCAAA= Archived-At: Subject: [COSE] WGLC, One more week 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 Jun 2016 00:51:51 -0000 Hi everyone, Just a gentle reminder that the WGLC on the COSE Messages draft closes a week from today, on June 10 2016. Due to timezones, schedules, and the black art of SMTP delivery, we can't guarantee any particular time during the day that the call will close. Therefore, if you've got something to say about the draft, please do so earlier in the week rather than later. No time like the present! The latest draft (12) is here: https://tools.ietf.org/html/draft-ietf-cose-msg-12 The issue tracker is here (but we'd prefer comments to the list in this period): https://github.com/cose-wg/cose-issues/issues Please read and review, and we're even looking for "yup, it looks good to me" from people if that's your take on things. Thanks everyone, -- Justin, your COSE chair From nobody Wed Jun 8 08:50:02 2016 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 1E8BF12D0FD for ; Wed, 8 Jun 2016 08:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 brWin4MukrvR for ; Wed, 8 Jun 2016 08:49:56 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 68C4E12D769 for ; Wed, 8 Jun 2016 08:49:56 -0700 (PDT) X-AuditID: 12074424-c87ff70000000add-1e-57583ea203aa 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 58.02.02781.2AE38575; Wed, 8 Jun 2016 11:49:55 -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 u58FnsAk020563 for ; Wed, 8 Jun 2016 11:49:54 -0400 Received: from [172.20.9.246] ([12.6.60.227]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u58FnIx0029028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 8 Jun 2016 11:49:53 -0400 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <87B21730-AD6A-4D00-AEBB-72E78A55B6C8@mit.edu> Date: Wed, 8 Jun 2016 10:50:02 -0500 To: cose Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUixG6nrrvYLiLcYMYiLotpW6eyOjB6LFny kymAMYrLJiU1J7MstUjfLoEro2HtB8aC9IpJ+0+wNDAGdDFycEgImEgcOeHQxcjFISTQxiSx aedddgjnCKPE9M5zzBDOXiaJ3d/+MnUxcnKwCahKTF/TAmYzC6hL/Jl3iRnC1pZYtvA1mC0s wCvRt2ELI4jNK2Al8XjbP3YQm0VAReLA3o1MIJtFBCQkLmwogyjRk9i0/i3YSAkBWYknJxex TGDknYVkwywkG2YhaVnAyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11wvN7NELzWldBMjOIxc VHYwdvd4H2IU4GBU4uE9oRceLsSaWFZcmXuIUZKDSUmUV9EdKMSXlJ9SmZFYnBFfVJqTWnyI UYKDWUmEV942IlyINyWxsiq1KB8mJc3BoiTOy8jAwCAkkJ5YkpqdmlqQWgSTleHgUJLg3QHS KFiUmp5akZaZU4KQZuLgBBnOAzS8B2x4cUFibnFmOkT+FKMlx7Np19YycbwAkwt+3F7LJMSS l5+XKiXO22oD1CAA0pBRmgc3E5QWeNhsHr9iFAd6UZh3I8hYHmBKgZv6CmghE9DC5UfCQRaW JCKkpBoYzyRM3TBL/9KSzP8Tuz2rZ/cm7Tttuq1VrNz/UvvauD9zEo4wJe8SZG2f5NLQIBl/ fO6C9/Xp01e+qf/uM71167yItZsjDE8vyru2jito1rlyqyuS2woTFLM9nDR9z34weKH5xV+m LPnwvifhbTPl/hSaP30xe1Pl9dpVK6rDdvbu31P5oCzDW4mlOCPRUIu5qDgRABZ/JRXmAgAA Archived-At: Subject: [COSE] WGLC 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: Wed, 08 Jun 2016 15:50:01 -0000 Hi everyone, Has anybody read the draft? Comments, thoughts, snide remarks? =E2=80=94 Justin From nobody Wed Jun 8 09:09:07 2016 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 CE93D12D5C3 for ; Wed, 8 Jun 2016 09:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SUBJ_ALL_CAPS=1.506] autolearn=no 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 tSrKkk-VhjyD for ; Wed, 8 Jun 2016 09:09:04 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09AC612D6A1 for ; Wed, 8 Jun 2016 09:07:23 -0700 (PDT) Received: from mfilter30-d.gandi.net (mfilter30-d.gandi.net [217.70.178.161]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id B06901720AF; Wed, 8 Jun 2016 18:07:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter30-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter30-d.gandi.net (mfilter30-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 0l0ehTRDkx7h; Wed, 8 Jun 2016 18:07:20 +0200 (CEST) X-Originating-IP: 134.102.27.196 Received: from eduroam-pool6-0964.wlan.uni-bremen.de (eduroam-pool6-0964.wlan.uni-bremen.de [134.102.27.196]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id CF58E1720BD; Wed, 8 Jun 2016 18:07:19 +0200 (CEST) Message-ID: <575842B6.5070401@tzi.org> Date: Wed, 08 Jun 2016 18:07:18 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Justin Richer References: <87B21730-AD6A-4D00-AEBB-72E78A55B6C8@mit.edu> In-Reply-To: <87B21730-AD6A-4D00-AEBB-72E78A55B6C8@mit.edu> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: cose Subject: Re: [COSE] WGLC 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: Wed, 08 Jun 2016 16:09:06 -0000 Hi Justin, expect my full review by the end of this week (and a pull request for the editorial nits). (Yes, there is a little work to do still, but so far I'm quite happy.) Grüße, Carsten Justin Richer wrote: > Hi everyone, > > Has anybody read the draft? Comments, thoughts, snide remarks? > > — Justin > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > From nobody Thu Jun 9 01:05:25 2016 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 B4DE012D1E4 for ; Thu, 9 Jun 2016 01:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 eQBBI_78QIyq for ; Thu, 9 Jun 2016 01:05:23 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA9D12D1AA for ; Thu, 9 Jun 2016 01:05:22 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-b6-57592340f792 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B2.32.27088.04329575; Thu, 9 Jun 2016 10:05:21 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.294.0; Thu, 9 Jun 2016 10:05:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q05xQbJG4rooHEjav3bwoYZCpqmZd5AGEbWPdNi9hBE=; b=MpU6hccxtmt7BF06mTDh4p+RYc9GU91afGQbfQ7BqlunzFpTnrppcQWrs4FVHnUoJwV5dhv6ihk0qp98p/1DNxN5fYVb7tOWKdjy8cPtUKHRsoxDA7K5snrImtgCxMz7bO0aAXQpx2TW65vUjoIfnGab2gjZ8wb92cuIEdkdOe4= Received: from AMXPR07MB070.eurprd07.prod.outlook.com (10.242.70.148) by AMXPR07MB072.eurprd07.prod.outlook.com (10.242.70.155) with Microsoft SMTP Server (TLS) id 15.1.497.12; Thu, 9 Jun 2016 08:05:19 +0000 Received: from AMXPR07MB070.eurprd07.prod.outlook.com ([169.254.14.191]) by AMXPR07MB070.eurprd07.prod.outlook.com ([169.254.14.191]) with mapi id 15.01.0506.016; Thu, 9 Jun 2016 08:05:19 +0000 From: Francesca Palombini To: Carsten Bormann , Justin Richer , "ietf@augustcellars.com" Thread-Topic: [COSE] WGLC Thread-Index: AQHRwZ1vgcw5q7en30S0UjzUsu+GeJ/fvG4AgAEGqfA= Date: Thu, 9 Jun 2016 08:05:19 +0000 Message-ID: References: <87B21730-AD6A-4D00-AEBB-72E78A55B6C8@mit.edu> <575842B6.5070401@tzi.org> In-Reply-To: <575842B6.5070401@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.81] x-ms-office365-filtering-correlation-id: 178c6c7e-a2bb-45d2-b7c7-08d3903ccc99 x-microsoft-exchange-diagnostics: 1; AMXPR07MB072; 5:s0A07NRjejGHLlbjajaUU4KdfRE8MVVy1zjLxDlWHT9T/FirovEpOKvhU80TpeK/944NyR2RnfvaSV5y3MLrGexoYoNaSS4Xj6wkRF6DaqKyXHZ9g9dw9ZElS+zWgBcnoxcW7VjCORzbxoEsfgMCAA==; 24:CLeuZk2FAI73cNDX4I0Q2R+eLjRuwi7WnUdzRTV7an9E+ggjwdeEh9JRyOVAlgAe6KZrgEfLtU7KRtkP2HKcF9nCXvCaeROD867XRSkmkuI=; 7:hJSxaRwoIuNxBdbcn/XWc7C1Jhsg3XMdVZr7GCqAiItSUzGSzdTOiUAGq395JlljIjdYmKMW5Irnn9EqQlClucNgWWQkFFgVU6e08DUmWBIeE46vfixTb8xpN+JdwK9H3rKOnEPJVcFNWuM8B0yGYRSDnB5LsvF+V7/Kc2h7Fjd71YiqU59s+mmW2egJSMlA4FULekXSa0EaxnBXWirrkQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB072; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AMXPR07MB072; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB072; x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(53754006)(13464003)(199003)(24454002)(189002)(11100500001)(5001770100001)(586003)(5004730100002)(19580405001)(106116001)(105586002)(106356001)(19580395003)(5003600100002)(76576001)(3280700002)(3660700001)(345774005)(6116002)(2501003)(74316001)(5008740100001)(97736004)(3846002)(81156014)(189998001)(102836003)(2950100001)(87936001)(2900100001)(5002640100001)(33656002)(122556002)(10400500002)(101416001)(9686002)(2906002)(50986999)(66066001)(54356999)(92566002)(8676002)(81166006)(8936002)(15975445007)(2171001)(76176999)(4326007)(68736007)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB072; H:AMXPR07MB070.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2016 08:05:19.3499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB072 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsUyM2K7uq6jcmS4wa/HnBZHptxltZi2dSqr xerp39ksNlx7yerA4rFxznQ2jyVLfjJ5NJ05yuwxbVFmAEsUl01Kak5mWWqRvl0CV8baxkvs BRMkK7a9v8jYwLhHoouRg0NCwERizl6OLkZOIFNM4sK99WwgtpDAEUaJ91elIOzjjBIT34p2 MXJxsAj0Mkv86/vBDuIICVxmlDh74DUrhHOUUWLlve/MIC1sAjYSFx6+ZwWxRQQqJPb17mAH sZkFJCQ2tE8AWyEMZP+5/QuqRlLia99LRgjbSqL13kcmEJtFQEXi8cfnYDavQJTEvzlT2CFO CpdYuHszWD2ngLrE3mO7wWYyAr3w/dQaJohd4hK3nsxngnhNQGLJnvPMELaoxMvH/1gh6pMl rtzuY4eIK0gcm7GSBcL2lbj69TYbyGMSAtNYJK4+mM0GkXCVmDhrLyuEnSnx9eZjqAVaEh1H ZjFBNKwFhtePf4yQ8JWRWNtkCRF/wSpxblULNIBTJZavbWWcwKg9C8mxs4BamAU0Jdbv0ocI K0pM6X7IPgvsf0GJkzOfsCxgZFnFKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJEZhYDm75bbCD 8eVzx0OMAhyMSjy8CVMjwoVYE8uKK3MPMUpwMCuJ8HLKR4YL8aYkVlalFuXHF5XmpBYfYpTm YFES5/V/qRguJJCeWJKanZpakFoEk2Xi4JRqYOwR9rgdcqw3zP1D0GP9fr97XxUvWV0zm9wg o9HTKFd1UsWnPGKhMF+hg/DZxGlx4soZPl5Wx3Jqdrd/f3LWYLL4y8V7p89b5jB3wcWWrdcn r5e8IKZZWBl9g/G/3tyXVYffa6WfOmnBWVTf2zMz6+mclylqnxWPVe9Kr4zNXKvGeerMkomH VyixFGckGmoxFxUnAgC0NZ5UKAMAAA== Archived-At: Cc: cose Subject: Re: [COSE] WGLC 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: Thu, 09 Jun 2016 08:05:24 -0000 SGVsbG8sDQoNCkNhcnN0ZW4gYW5kIEppbSwgSSBqdXN0IHNlbnQgYSBwdWxsIHJlcXVlc3QgdG8g Zml4IHNvbWUgZWRpdG9yaWFscyAoYnR3IHNvbWUgd2VyZSBhbHJlYWR5IGZpeGVkIGluIHRoZSBn aXQgY29tcGFyZWQgdG8gdGhlIGlldGYgb25lKSwgSSBtYXkgaGF2ZSBsZWZ0IHNvbWUgb2YgY291 cnNlLg0KDQpJIGFtIGhhcHB5IHdpdGggdGhlIGRyYWZ0LCBtaW5vciBjb21tZW50czoNCi0gdGhl IEJhc2UgSVYgaGFzIGJlZW4gYWRkZWQgdG8gdGhlIENPU0UgS2V5LCBidXQgaXMgbm90IGluIHRo ZSBDRERMLiBJcyB0aGVyZSBhIHJlYXNvbiBvciBpdCB3YXMgc2ltcGx5IGZvcmdvdHRlbj8gKHNl Y3Rpb24gNy4xKQ0KLSBJJ20gbm90IHN1cmUgd2hhdCB5b3Ugd2FudGVkIHRvIHNheSBpbiBhIHNl bnRlbmNlIGluIHNlY3Rpb24gMTEuMiwgd2hpY2ggaGFzIHNvbWUgZWRpdG9yaWFsLCBzbyBJIGNv dWxkbid0IGZpeCBpdDogIihUaGlzIHByYWN0aWNlIG1lYW5zIGlmIGFsZ29yaXRobSBBIGlzIGJy b2tlbiBhbmQgdGh1cyBjYW4gaXMgZWFzaWVyIHRvIGZpbmQsIHRoZSBrZXkgZGVyaXZlZCBmb3Ig YWxnb3JpdGhtIEIgd2lsbCBub3QgYmUgdGhlIHNhbWUgYXMgdGhlIGtleSBmb3IgYWxnb3JpdGht IEIuKSINCi0gU2FtZSB3aXRoIHRoaXMgc2VudGVuY2UgaW4gc2VjdGlvbiAxMi40LjEgIlNpbmNl IHRoZSBvbmx5IHRoZSBtYXRoIGlzIGNoYW5nZWQgYnkgY2hhbmdpbmcgdGhlIGN1cnZlLCB0aGUg Y3VydmUgaXMgbm90IGZpeGVkIGZvciBhbnkgb2YgdGhlIGFsZ29yaXRobSBpZGVudGlmaWVycyB3 ZSBkZWZpbmUuIiBNYXliZSBmaXhpbmcgdGhlIGVkaXRvcmlhbCB3aWxsIG1ha2UgaXQgbW9yZSBj bGVhciwgYnV0IHJpZ2h0IG5vdyBJIGRvbid0IHJlYWxseSB1bmRlcnN0YW5kIGl0Lg0KLSBFeGFt cGxlIEMuMi4xLiBpcyBtaXNzaW5nIHRoZSBjb21tZW50IGZvciB0aGUgc2lnbmF0dXJlDQoNCk90 aGVyd2lzZSwgSSBhbSBzYXRpc2ZpZWQgd2l0aCB0aGUgZHJhZnQgKGluY2x1ZGluZyB0aGUgYXBw ZW5kaWNlcyksIHRoYW5rIHlvdSBmb3IgdGhlIGdyZWF0IHdvcmshIEkgYXBwcmVjaWF0ZWQgdGhh dCB5b3UgaW50cm9kdWNlIHRoZSB0YWJsZSB3aXRoIHRoZSBwYXJhbWV0ZXJzIGluIHRoZSBiZWdp bm5pbmcgb2YgZWFjaCBzZWN0aW9uLiBJIHRoaW5rIGl0IG1ha2VzIGl0IGVhc2llciB0byB1bmRl cnN0YW5kIGF0IHdoYXQgbGV2ZWwgdGhvc2UgcGFyYW1ldGVycyBzaG91bGQgYmUgdXNlZC4NCg0K T25lIHF1ZXN0aW9uLCBtYXliZSBJIG1pc3NlZCBpdCBvciBtYXliZSBJIGxhY2sgZXhwZXJpZW5j ZTogSSBzZWUgeW91IGRlZmluZSBpbiBzZWN0aW9uIDE1LiAiQXBwbGljYXRpb24gUHJvZmlsaW5n IENvbnNpZGVyYXRpb25zIiB0aGF0IGFuIGFwcGxpY2F0aW9uIG1heSBkZWZpbmUgbmV3IGhlYWRl ciBwYXJhbWV0ZXJzOyB3aGF0IHdvdWxkIGJlIHRoZSBwcm9jZXNzIHRvIHJlZ2lzdGVyIGxhYmVs cyBmb3IgbmV3IHBhcmFtZXRlcnM/DQoNCkZyYW5jZXNjYQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBDT1NFIFttYWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQpTZW50OiBkZW4gOCBqdW5pIDIwMTYgMTg6MDcNClRv OiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+DQpDYzogY29zZSA8Y29zZUBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbQ09TRV0gV0dMQw0KDQpIaSBKdXN0aW4sDQoNCmV4cGVjdCBteSBm dWxsIHJldmlldyBieSB0aGUgZW5kIG9mIHRoaXMgd2VlayAoYW5kIGEgcHVsbCByZXF1ZXN0IGZv ciB0aGUgZWRpdG9yaWFsIG5pdHMpLg0KDQooWWVzLCB0aGVyZSBpcyBhIGxpdHRsZSB3b3JrIHRv IGRvIHN0aWxsLCBidXQgc28gZmFyIEknbSBxdWl0ZSBoYXBweS4pDQoNCkdyw7zDn2UsIENhcnN0 ZW4NCg0KDQpKdXN0aW4gUmljaGVyIHdyb3RlOg0KPiBIaSBldmVyeW9uZSwNCj4gDQo+IEhhcyBh bnlib2R5IHJlYWQgdGhlIGRyYWZ0PyBDb21tZW50cywgdGhvdWdodHMsIHNuaWRlIHJlbWFya3M/ DQo+IA0KPiAg4oCUIEp1c3Rpbg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gQ09TRSBtYWlsaW5nIGxpc3QNCj4gQ09TRUBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UNCj4gDQo+IA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ09TRSBtYWls aW5nIGxpc3QNCkNPU0VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY29zZQ0K From nobody Thu Jun 9 06:30:04 2016 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 978B912D684; Thu, 9 Jun 2016 06:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160609133002.16789.91485.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2016 06:30:02 -0700 Archived-At: Cc: Kathleen.Moriarty.ietf@gmail.com, cose-chairs@ietf.org, cose@ietf.org, kepeng.lkp@alibaba-inc.com Subject: [COSE] cose - Update to a Meeting Session Request for IETF 96 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 13:30:03 -0000 An update to a meeting session request has just been submitted by Kepeng Li, a Chair of the cose working group. --------------------------------------------------------- Working Group Name: CBOR Object Signing and Encryption Area Name: Security Area Session Requester: Kepeng Li Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: ace core oauth abfab sacm radext dime tls Second Priority: dane httpauth kitten saag Third Priority: httpbis sidr Special Requests: --------------------------------------------------------- From nobody Thu Jun 9 11:33:41 2016 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 2E11212D79D for ; Thu, 9 Jun 2016 11:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SUBJ_ALL_CAPS=1.506] autolearn=no 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 q29KRgJMK3pd for ; Thu, 9 Jun 2016 11:33:37 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EB612D7B1 for ; Thu, 9 Jun 2016 11:33:37 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id E514E2CA5E; Thu, 9 Jun 2016 11:33:36 -0700 (PDT) From: "Jim Schaad" To: "'Francesca Palombini'" , "'Carsten Bormann'" , "'Justin Richer'" References: <87B21730-AD6A-4D00-AEBB-72E78A55B6C8@mit.edu> <575842B6.5070401@tzi.org> In-Reply-To: Date: Thu, 9 Jun 2016 11:33:36 -0700 Message-ID: <05d601d1c27d$6fb330d0$4f199270$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH1IsgQ1lNISR9mQJ01+1RyLGXdawHJHAbjAR8UKLefg2d/AA== Content-Language: en-us Archived-At: Cc: 'cose' Subject: Re: [COSE] WGLC 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: Thu, 09 Jun 2016 18:33:39 -0000 Thanks for the review. Comments interspersed below > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Francesca = Palombini > Sent: Thursday, June 09, 2016 1:05 AM > To: Carsten Bormann ; Justin Richer ; > ietf@augustcellars.com > Cc: cose > Subject: Re: [COSE] WGLC >=20 > Hello, >=20 > Carsten and Jim, I just sent a pull request to fix some editorials = (btw some were > already fixed in the git compared to the ietf one), I may have left = some of > course. >=20 > I am happy with the draft, minor comments: > - the Base IV has been added to the COSE Key, but is not in the CDDL. = Is there a > reason or it was simply forgotten? (section 7.1) That was an oversight. > - I'm not sure what you wanted to say in a sentence in section 11.2, = which has > some editorial, so I couldn't fix it: "(This practice means if = algorithm A is broken > and thus can is easier to find, the key derived for algorithm B will = not be the > same as the key for algorithm B.)" The last B should be an A.=20 > - Same with this sentence in section 12.4.1 "Since the only the math = is changed > by changing the curve, the curve is not fixed for any of the algorithm = identifiers > we define." Maybe fixing the editorial will make it more clear, but = right now I > don't really understand it. Does this work better? The math used to obtain the computed secret is based on the curve = selected and not on the ECDH algorithm. For this reason, a new algorithm does not need to be defined for each of = the curves. Note that I am planning on changing the title of the next bullet to = "Computed Secret to Shared Secret" and update the text following = accordingly. > - Example C.2.1. is missing the comment for the signature Your right - how odd. >=20 > Otherwise, I am satisfied with the draft (including the appendices), = thank you for > the great work! I appreciated that you introduce the table with the = parameters > in the beginning of each section. I think it makes it easier to = understand at what > level those parameters should be used. >=20 > One question, maybe I missed it or maybe I lack experience: I see you = define in > section 15. "Application Profiling Considerations" that an application = may define > new header parameters; what would be the process to register labels = for new > parameters? This is done by the normal IANA processes. That is one writes a = document of some type and requests that an IANA registration is done in = the appropriate registry. An example of how this would be done can be = found in section 16.9. If one writes the document as an RFC, the request to IANA occurs = automatically as part of the workflow of a document. If one is writing = the document outside of the IETF then one needs to send an email to IANA = to request the registration. As part of the IANA registration process, a designated export for the = registry (to be determined by the IESG) would review the request and = either approve it, suggest changes or deny the registration. I have = not created a template for the registration, but the set of fields to be = included in the registration are defined. Section 16.10 gives general = guidance to the reviewers=20 Jim >=20 > Francesca >=20 >=20 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: den 8 juni 2016 18:07 > To: Justin Richer > Cc: cose > Subject: Re: [COSE] WGLC >=20 > Hi Justin, >=20 > expect my full review by the end of this week (and a pull request for = the editorial > nits). >=20 > (Yes, there is a little work to do still, but so far I'm quite happy.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Justin Richer wrote: > > Hi everyone, > > > > Has anybody read the draft? Comments, thoughts, snide remarks? > > > > =E2=80=94 Justin > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > > > >=20 > _______________________________________________ > 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 From nobody Fri Jun 10 00:23:03 2016 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 9B98012D0CA for ; Fri, 10 Jun 2016 00:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 ph4FqUiqGkLQ for ; Fri, 10 Jun 2016 00:22:59 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59FD12B046 for ; Fri, 10 Jun 2016 00:22:59 -0700 (PDT) Received: from mfilter31-d.gandi.net (mfilter31-d.gandi.net [217.70.178.162]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 707A817214F; Fri, 10 Jun 2016 09:22:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter31-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter31-d.gandi.net (mfilter31-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 21lPtSYvZ-pe; Fri, 10 Jun 2016 09:22:56 +0200 (CEST) X-Originating-IP: 134.102.90.80 Received: from eduroam-pool10-081.wlan.uni-bremen.de (eduroam-pool10-081.wlan.uni-bremen.de [134.102.90.80]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id A60A6172131; Fri, 10 Jun 2016 09:22:56 +0200 (CEST) Message-ID: <575A6ACE.7040808@tzi.org> Date: Fri, 10 Jun 2016 09:22:54 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "cose@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [COSE] PartyInfo 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 Jun 2016 07:23:02 -0000 Maybe a minor nit, but shouldn't be PartyInfo = ( ? nonce : bstr / int, ? identity : bstr, ? other : bstr, ) better be done as PartyInfo = ( nonce : bstr / int / nil, identity : bstr / nil, ? other : bstr, ) (This is used in an array context, so any non-final optionals create a potential for mixup.) While the attack surface of any confusion that can be created here is rather small, I don't think we have to "save those bytes". Grüße, Carsten PS.: Yes, this could also be done as: PartyInfo = ( nonce : bstr / int / nil, ? (identity : bstr / nil, ? other : bstr), ) From nobody Fri Jun 10 01:51:41 2016 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 C411012D0DF for ; Fri, 10 Jun 2016 01:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.439 X-Spam-Level: X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SUBJ_AS_SEEN=1.461] autolearn=no 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 oGO-WmNTqu-M for ; Fri, 10 Jun 2016 01:51:39 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3554B12D0FF for ; Fri, 10 Jun 2016 01:51:39 -0700 (PDT) Received: from mfilter33-d.gandi.net (mfilter33-d.gandi.net [217.70.178.164]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id DA11BFB8E5; Fri, 10 Jun 2016 10:51:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter33-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter33-d.gandi.net (mfilter33-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id czdNJbTkQdoB; Fri, 10 Jun 2016 10:51:36 +0200 (CEST) X-Originating-IP: 134.102.90.80 Received: from eduroam-pool10-081.wlan.uni-bremen.de (eduroam-pool10-081.wlan.uni-bremen.de [134.102.90.80]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 1F9C8FB8E0; Fri, 10 Jun 2016 10:51:35 +0200 (CEST) Message-ID: <575A7F96.4080102@tzi.org> Date: Fri, 10 Jun 2016 10:51:34 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "cose@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [COSE] COSE as seen by a bunch of students 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 Jun 2016 08:51:41 -0000 Not quite a WGLC review, but here's what a group of students had to say about draft-ietf-cose-msg-12.txt as part of a recent class assignment (with permission, excerpted and translated by yours truly). (Please don't read this as a criticism of CMS, the students just happened to need to look at both CMS and COSE for the assignment.) My main point here is that the -msg draft indeed appears to be quite accessible for new people to acquaint themselves with COSE, and I'm happy to see that we seem to have achieved that. Grüße, Carsten ... The COSE draft provides current encryption algorithms and hashes (EdDSA, SHA-2, AES, ChaCha20/Poly1305, ECDH). It is prepared for the future by using IANA for defining and publishing identifiers for new algorithms, so that the relevant algorithms can all be found in one place. ... Since COSE is based on CBOR, some information can be expressed in a more compact and simple way [than with CMS]. A single CBOR parser can be used for all formats. In addition, all formats have a very similar structure that is sharing the header: an array containing two headers with meta information as well as a field for payloads and optional fields for signatures and recipients. COSE has been developed for the use on devices with constrained resources, so the parsing of the packets should use minimal time, energy and memory. ... [In comparing CMS and COSE:] There is no equivalent [in COSE] for the Digested-data Content Type [in CMS]. ... In reading the available source documents it became apparent that the COSE draft places a lot more attention on examples and howto's, making the draft much more readable. ASN.1 is getting in the way of understanding, CBOR is easier to understand. Also, there are no test vectors in the CMS RFCs we used. From nobody Fri Jun 10 02:34:03 2016 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 ECDA812D572 for ; Fri, 10 Jun 2016 02:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 GpdBJJ5DPCka for ; Fri, 10 Jun 2016 02:33:59 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02F012D149 for ; Fri, 10 Jun 2016 02:33:58 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-6a-575a898442f7 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 65.76.12926.4898A575; Fri, 10 Jun 2016 11:33:56 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.294.0; Fri, 10 Jun 2016 11:33:55 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RJpd6XPW19Fi+DExnc6rorqqMWHGWsCYGfkkbCAf6sc=; b=VGvvh1iUgIxbWoszHd+piIJewjITpDEpeUTseN+auG7Gi8dysd7uGZVbW17XZXX0F8ak5XAnkCSd49/K0E6hJJTr7LbXhjM7GYk0cxxZMVmGc7z9ADS9M9td96aktf2oMAzKLcE14D1N6LHsEhCrjLIanihC6avOUiMHIJKQSis= Received: from AMXPR07MB070.eurprd07.prod.outlook.com (10.242.70.148) by AMXPR07MB069.eurprd07.prod.outlook.com (10.242.70.147) with Microsoft SMTP Server (TLS) id 15.1.506.9; Fri, 10 Jun 2016 09:33:54 +0000 Received: from AMXPR07MB070.eurprd07.prod.outlook.com ([169.254.14.191]) by AMXPR07MB070.eurprd07.prod.outlook.com ([169.254.14.191]) with mapi id 15.01.0506.016; Fri, 10 Jun 2016 09:33:55 +0000 From: Francesca Palombini To: Jim Schaad Thread-Topic: [COSE] WGLC Thread-Index: AQHRwZ1vgcw5q7en30S0UjzUsu+GeJ/fvG4AgAEGqfCAALSMAIAA9yOQ Date: Fri, 10 Jun 2016 09:33:54 +0000 Message-ID: References: <87B21730-AD6A-4D00-AEBB-72E78A55B6C8@mit.edu> <575842B6.5070401@tzi.org> <05d601d1c27d$6fb330d0$4f199270$@augustcellars.com> In-Reply-To: <05d601d1c27d$6fb330d0$4f199270$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.81] x-ms-office365-filtering-correlation-id: 96da35b4-73c7-4435-ab9a-08d391125765 x-microsoft-exchange-diagnostics: 1; AMXPR07MB069; 5:9lGRwT5ycmqDCVuLhZHpuDP2KUgd9Q1Pz3Su8RsbXahxX6GdLn12YqT90K/Q7N3ATkQKOWl/FJH2BfjVavWPdTiI4MiCjxlSJ4o+ZAAH4cUr0frZ79sShE3WZlJrb4eHfNX3d/95yUbhaPfqZKz/ew==; 24:FCnRYUou0UquYah586V45PTHIE4H3Lh3gYfVdxMz4WD5mfLGKZBL/+az8hnRkcxsKgZ8xvf+eYtuuO5mAZqh8VFDWNlixZUiNuN0Hp4iP7c=; 7:YQxfdD7/nT9eI3TwUzl6APTXOn6U4rRMBzor0eqHJVjB83cUvCFFaL9XuwO9jpvFacJc2l4WO33aPGUhYoq3a02j4y1kvaopLxnIyGFoOo82Yncn7h+zQDG6dQ4bP3FaRFvIFXBtP+C6aw/0z3BXaV1qe0PJ88Zw18+K6NFbXYLYfMZqunOL3s4/GArQ0EM1SetBq290wyRTx0EngErPiw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB069; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(271806183753584); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMXPR07MB069; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB069; x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(53754006)(24454002)(51914003)(13464003)(189002)(199003)(68736007)(3660700001)(106356001)(81166006)(93886004)(345774005)(5003600100002)(86362001)(8676002)(76576001)(33656002)(76176999)(6116002)(5008740100001)(110136002)(4326007)(189998001)(97736004)(3280700002)(106116001)(105586002)(5004730100002)(122556002)(50986999)(15975445007)(5002640100001)(66066001)(9686002)(8936002)(586003)(3846002)(74316001)(54356999)(2900100001)(2950100001)(102836003)(10400500002)(87936001)(81156014)(19580405001)(101416001)(92566002)(19580395003)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB069; H:AMXPR07MB070.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2016 09:33:54.7191 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB069 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42KZGbHdW7elMyrc4NdhRYtpW6eyWqye/p3N gclj45zpbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4fGsHS8Eak4r1P5vYGhgbjLsYOTkkBEwk Lu97xw5hi0lcuLeerYuRi0NI4AijROfDRiYI5ySjxLbDTYwgDotAL7PEk3srGCEylxkljr57 wgLhHGOUOP5iMxPIMDYBG4kLD9+zgtgiAuoSW1ffBIszC0hJnGifzAhiCwtISPy5/QuqRlLi a99LRgjbTeLqy3Y2EJtFQFVi/eE9zCA2r0CUxLlnXVCb7zFKdG/5BVbEKeAgMalpO1gRI9AX 30+tgVomLnHryXwmiO8EJJbsOc8MYYtKvHz8jxWiPlniyu0+aAgoSBybsZIFwvaVePJoOTPI MgmBaSwSi2fshmp2lZjacANoKAeQnSmxd5sGhOktcbfNAqJ8LaPEvAsrWSHKZSSOLTvOCJF4 wipxtnM52JdCAqkSy9e2Mk5g1J6F5NZZQLOYBTQl1u/ShwgrSkzpfsg+C+x/QYmTM5+wLGBk WcUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRmDgObvmtuoPx8hvHQ4wCHIxKPLwPnkWGC7Em lhVX5h5ilOBgVhLhza6OChfiTUmsrEotyo8vKs1JLT7EKM3BoiTO6/9SMVxIID2xJDU7NbUg tQgmy8TBKdXAaGT9RPaY1E3rvK7eCWGZX58Xzr+bLvuz6w3fFpljGvu23/7LpFe3/8x/1unn dkefmahSwXLnj5qNyuVjFj/jturINjrddzd8rlNe+G437/82A7GWxHYpd6uTybdDNy/3m8ki dEGkSudOa2fcsZQ2tvWHNjLMOizi7HwvzPuZtQH3Ux2nU/c0lFiKMxINtZiLihMBasc2GBgD AAA= Archived-At: Cc: 'cose' Subject: Re: [COSE] WGLC 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 Jun 2016 09:34:02 -0000 SGkgSmltLA0KDQpBbnN3ZXJzIGlubGluZS4NCg0KRnJhbmNlc2NhDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBKaW0gU2NoYWFkIFttYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbV0gDQpTZW50OiBkZW4gOSBqdW5pIDIwMTYgMjA6MzQNClRvOiBGcmFuY2VzY2EgUGFsb21i aW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT47ICdDYXJzdGVuIEJvcm1hbm4n IDxjYWJvQHR6aS5vcmc+OyAnSnVzdGluIFJpY2hlcicgPGpyaWNoZXJAbWl0LmVkdT4NCkNjOiAn Y29zZScgPGNvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0NPU0VdIFdHTEMNCg0KVGhhbmtz IGZvciB0aGUgcmV2aWV3LiAgQ29tbWVudHMgaW50ZXJzcGVyc2VkIGJlbG93DQoNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDT1NFIFttYWlsdG86Y29zZS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRnJhbmNlc2NhIA0KPiBQYWxvbWJpbmkNCj4gU2VudDog VGh1cnNkYXksIEp1bmUgMDksIDIwMTYgMTowNSBBTQ0KPiBUbzogQ2Fyc3RlbiBCb3JtYW5uIDxj YWJvQHR6aS5vcmc+OyBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+OyANCj4gaWV0ZkBh dWd1c3RjZWxsYXJzLmNvbQ0KPiBDYzogY29zZSA8Y29zZUBpZXRmLm9yZz4NCj4gU3ViamVjdDog UmU6IFtDT1NFXSBXR0xDDQo+IA0KPiBIZWxsbywNCj4gDQo+IENhcnN0ZW4gYW5kIEppbSwgSSBq dXN0IHNlbnQgYSBwdWxsIHJlcXVlc3QgdG8gZml4IHNvbWUgZWRpdG9yaWFscyANCj4gKGJ0dyBz b21lIHdlcmUgYWxyZWFkeSBmaXhlZCBpbiB0aGUgZ2l0IGNvbXBhcmVkIHRvIHRoZSBpZXRmIG9u ZSksIEkgDQo+IG1heSBoYXZlIGxlZnQgc29tZSBvZiBjb3Vyc2UuDQo+IA0KPiBJIGFtIGhhcHB5 IHdpdGggdGhlIGRyYWZ0LCBtaW5vciBjb21tZW50czoNCj4gLSB0aGUgQmFzZSBJViBoYXMgYmVl biBhZGRlZCB0byB0aGUgQ09TRSBLZXksIGJ1dCBpcyBub3QgaW4gdGhlIENEREwuIA0KPiBJcyB0 aGVyZSBhIHJlYXNvbiBvciBpdCB3YXMgc2ltcGx5IGZvcmdvdHRlbj8gKHNlY3Rpb24gNy4xKQ0K DQpUaGF0IHdhcyBhbiBvdmVyc2lnaHQuDQoNCj4gLSBJJ20gbm90IHN1cmUgd2hhdCB5b3Ugd2Fu dGVkIHRvIHNheSBpbiBhIHNlbnRlbmNlIGluIHNlY3Rpb24gMTEuMiwgDQo+IHdoaWNoIGhhcyBz b21lIGVkaXRvcmlhbCwgc28gSSBjb3VsZG4ndCBmaXggaXQ6ICIoVGhpcyBwcmFjdGljZSBtZWFu cyANCj4gaWYgYWxnb3JpdGhtIEEgaXMgYnJva2VuIGFuZCB0aHVzIGNhbiBpcyBlYXNpZXIgdG8g ZmluZCwgdGhlIGtleSANCj4gZGVyaXZlZCBmb3IgYWxnb3JpdGhtIEIgd2lsbCBub3QgYmUgdGhl IHNhbWUgYXMgdGhlIGtleSBmb3IgYWxnb3JpdGhtIEIuKSINCg0KVGhlIGxhc3QgQiBzaG91bGQg YmUgYW4gQS4gDQoNCltGUF0gT2ssIHRoZW4gdGhhdCAiY2FuIGlzIiBzaG91bGQgcHJvYmFibHkg YmUgInRoZSBrZXkgaXMiLCBvciBzb21ldGhpbmcgZWxzZT8ganVzdCBhbiBlZGl0b3JpYWwgYWdh aW4uDQoNCj4gLSBTYW1lIHdpdGggdGhpcyBzZW50ZW5jZSBpbiBzZWN0aW9uIDEyLjQuMSAiU2lu Y2UgdGhlIG9ubHkgdGhlIG1hdGggDQo+IGlzIGNoYW5nZWQgYnkgY2hhbmdpbmcgdGhlIGN1cnZl LCB0aGUgY3VydmUgaXMgbm90IGZpeGVkIGZvciBhbnkgb2YgDQo+IHRoZSBhbGdvcml0aG0gaWRl bnRpZmllcnMgd2UgZGVmaW5lLiIgTWF5YmUgZml4aW5nIHRoZSBlZGl0b3JpYWwgd2lsbCANCj4g bWFrZSBpdCBtb3JlIGNsZWFyLCBidXQgcmlnaHQgbm93IEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3Rh bmQgaXQuDQoNCkRvZXMgdGhpcyB3b3JrIGJldHRlcj8NCg0KVGhlIG1hdGggdXNlZCB0byBvYnRh aW4gdGhlIGNvbXB1dGVkIHNlY3JldCBpcyBiYXNlZCBvbiB0aGUgY3VydmUgc2VsZWN0ZWQgYW5k IG5vdCBvbiB0aGUgRUNESCBhbGdvcml0aG0uDQpGb3IgdGhpcyByZWFzb24sIGEgbmV3IGFsZ29y aXRobSBkb2VzIG5vdCBuZWVkIHRvIGJlIGRlZmluZWQgZm9yIGVhY2ggb2YgdGhlIGN1cnZlcy4N Cg0KTm90ZSB0aGF0IEkgYW0gcGxhbm5pbmcgb24gY2hhbmdpbmcgdGhlIHRpdGxlIG9mIHRoZSBu ZXh0IGJ1bGxldCB0byAiQ29tcHV0ZWQgU2VjcmV0IHRvIFNoYXJlZCBTZWNyZXQiIGFuZCB1cGRh dGUgdGhlIHRleHQgZm9sbG93aW5nIGFjY29yZGluZ2x5Lg0KDQpbRlBdIFllcyBpdCBkb2VzLCBh bmQgSSB0aGluayB0aGlzIGlzIGEgZ29vZCB0aXRsZSBjaGFuZ2UgdG9vLg0KDQo+IC0gRXhhbXBs ZSBDLjIuMS4gaXMgbWlzc2luZyB0aGUgY29tbWVudCBmb3IgdGhlIHNpZ25hdHVyZQ0KDQpZb3Vy IHJpZ2h0IC0gaG93IG9kZC4NCg0KPiANCj4gT3RoZXJ3aXNlLCBJIGFtIHNhdGlzZmllZCB3aXRo IHRoZSBkcmFmdCAoaW5jbHVkaW5nIHRoZSBhcHBlbmRpY2VzKSwgDQo+IHRoYW5rIHlvdSBmb3Ig dGhlIGdyZWF0IHdvcmshIEkgYXBwcmVjaWF0ZWQgdGhhdCB5b3UgaW50cm9kdWNlIHRoZSANCj4g dGFibGUgd2l0aCB0aGUgcGFyYW1ldGVycyBpbiB0aGUgYmVnaW5uaW5nIG9mIGVhY2ggc2VjdGlv bi4gSSB0aGluayBpdCANCj4gbWFrZXMgaXQgZWFzaWVyIHRvIHVuZGVyc3RhbmQgYXQgd2hhdCBs ZXZlbCB0aG9zZSBwYXJhbWV0ZXJzIHNob3VsZCBiZSB1c2VkLg0KPiANCj4gT25lIHF1ZXN0aW9u LCBtYXliZSBJIG1pc3NlZCBpdCBvciBtYXliZSBJIGxhY2sgZXhwZXJpZW5jZTogSSBzZWUgeW91 IA0KPiBkZWZpbmUgaW4gc2VjdGlvbiAxNS4gIkFwcGxpY2F0aW9uIFByb2ZpbGluZyBDb25zaWRl cmF0aW9ucyIgdGhhdCBhbiANCj4gYXBwbGljYXRpb24gbWF5IGRlZmluZSBuZXcgaGVhZGVyIHBh cmFtZXRlcnM7IHdoYXQgd291bGQgYmUgdGhlIA0KPiBwcm9jZXNzIHRvIHJlZ2lzdGVyIGxhYmVs cyBmb3IgbmV3IHBhcmFtZXRlcnM/DQoNClRoaXMgaXMgZG9uZSBieSB0aGUgbm9ybWFsIElBTkEg cHJvY2Vzc2VzLiAgVGhhdCBpcyBvbmUgd3JpdGVzIGEgZG9jdW1lbnQgb2Ygc29tZSB0eXBlIGFu ZCByZXF1ZXN0cyB0aGF0IGFuIElBTkEgcmVnaXN0cmF0aW9uIGlzIGRvbmUgaW4gdGhlIGFwcHJv cHJpYXRlIHJlZ2lzdHJ5LiAgIEFuIGV4YW1wbGUgb2YgaG93IHRoaXMgd291bGQgYmUgZG9uZSBj YW4gYmUgZm91bmQgaW4gc2VjdGlvbiAxNi45Lg0KSWYgb25lIHdyaXRlcyB0aGUgZG9jdW1lbnQg YXMgYW4gUkZDLCB0aGUgcmVxdWVzdCB0byBJQU5BIG9jY3VycyBhdXRvbWF0aWNhbGx5IGFzIHBh cnQgb2YgdGhlIHdvcmtmbG93IG9mIGEgZG9jdW1lbnQuICBJZiBvbmUgaXMgd3JpdGluZyB0aGUg ZG9jdW1lbnQgb3V0c2lkZSBvZiB0aGUgSUVURiB0aGVuIG9uZSBuZWVkcyB0byBzZW5kIGFuIGVt YWlsIHRvIElBTkEgdG8gcmVxdWVzdCB0aGUgcmVnaXN0cmF0aW9uLg0KDQpBcyBwYXJ0IG9mIHRo ZSBJQU5BIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLCBhIGRlc2lnbmF0ZWQgZXhwb3J0IGZvciB0aGUg cmVnaXN0cnkgKHRvIGJlIGRldGVybWluZWQgYnkgdGhlIElFU0cpIHdvdWxkIHJldmlldyB0aGUg cmVxdWVzdCBhbmQgZWl0aGVyIGFwcHJvdmUgaXQsIHN1Z2dlc3QgY2hhbmdlcyBvciBkZW55IHRo ZSByZWdpc3RyYXRpb24uICAgSSBoYXZlIG5vdCBjcmVhdGVkIGEgdGVtcGxhdGUgZm9yIHRoZSBy ZWdpc3RyYXRpb24sIGJ1dCB0aGUgc2V0IG9mIGZpZWxkcyB0byBiZSBpbmNsdWRlZCBpbiB0aGUg cmVnaXN0cmF0aW9uIGFyZSBkZWZpbmVkLiAgU2VjdGlvbiAxNi4xMCBnaXZlcyBnZW5lcmFsIGd1 aWRhbmNlIHRvIHRoZSByZXZpZXdlcnMgDQoNCltGUF0gT2suIHRoYW5rcyBmb3IgdGhlIGV4cGxh bmF0aW9uIQ0KDQpKaW0NCg0KDQo+IA0KPiBGcmFuY2VzY2ENCj4gDQo+IA0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDT1NFIFttYWlsdG86Y29zZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQo+IFNlbnQ6IGRlbiA4IGp1bmkgMjAx NiAxODowNw0KPiBUbzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1Pg0KPiBDYzogY29z ZSA8Y29zZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtDT1NFXSBXR0xDDQo+IA0KPiBIaSBK dXN0aW4sDQo+IA0KPiBleHBlY3QgbXkgZnVsbCByZXZpZXcgYnkgdGhlIGVuZCBvZiB0aGlzIHdl ZWsgKGFuZCBhIHB1bGwgcmVxdWVzdCBmb3IgDQo+IHRoZSBlZGl0b3JpYWwgbml0cykuDQo+IA0K PiAoWWVzLCB0aGVyZSBpcyBhIGxpdHRsZSB3b3JrIHRvIGRvIHN0aWxsLCBidXQgc28gZmFyIEkn bSBxdWl0ZSBoYXBweS4pDQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQo+IA0KPiANCj4gSnVzdGlu IFJpY2hlciB3cm90ZToNCj4gPiBIaSBldmVyeW9uZSwNCj4gPg0KPiA+IEhhcyBhbnlib2R5IHJl YWQgdGhlIGRyYWZ0PyBDb21tZW50cywgdGhvdWdodHMsIHNuaWRlIHJlbWFya3M/DQo+ID4NCj4g PiAg4oCUIEp1c3Rpbg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBDT1NFIG1haWxpbmcgbGlzdA0KPiA+IENPU0VAaWV0Zi5vcmcN Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UNCj4gPg0KPiA+ DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBDT1NFIG1haWxpbmcgbGlzdA0KPiBDT1NFQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY29zZQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBDT1NFIG1haWxpbmcgbGlzdA0KPiBDT1NFQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZQ0KDQo= From nobody Fri Jun 10 05:35:21 2016 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 1BDA112B008 for ; Fri, 10 Jun 2016 05:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 FN2KCWlEpkn8 for ; Fri, 10 Jun 2016 05:35:18 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773AE12D99E for ; Fri, 10 Jun 2016 05:35:18 -0700 (PDT) Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 0593DFB8CD; Fri, 10 Jun 2016 14:35:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter19-d.gandi.net (mfilter19-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id XJHcgyC_QVwE; Fri, 10 Jun 2016 14:35:15 +0200 (CEST) X-Originating-IP: 134.102.70.25 Received: from eduroam-pool9-026.wlan.uni-bremen.de (eduroam-pool9-026.wlan.uni-bremen.de [134.102.70.25]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 3572FFB8D1; Fri, 10 Jun 2016 14:35:14 +0200 (CEST) Message-ID: <575AB401.9080500@tzi.org> Date: Fri, 10 Jun 2016 14:35:13 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "cose@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [COSE] Helping with implementation consistency? 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 Jun 2016 12:35:20 -0000 One of the nice things about JOSE is that the various labels have a defined name, which is then re-used as a variable or field name in an implementation. We are not really providing the same level of service to implementers. Grüße, Carsten From nobody Fri Jun 10 09:16:12 2016 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 5005812D11D for ; Fri, 10 Jun 2016 09:16:10 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 tQCnv0xQ6YZc for ; Fri, 10 Jun 2016 09:16:08 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F1F12D11C for ; Fri, 10 Jun 2016 09:16:07 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-a5-575ae7c6fe1a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DB.36.12516.6C7EA575; Fri, 10 Jun 2016 18:16:06 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.158]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0294.000; Fri, 10 Jun 2016 18:16:05 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad Thread-Topic: [COSE] WGLC, One more week Thread-Index: AQHRvftKXiBym6eodUO2KqwCqX86l5/i6wEA Date: Fri, 10 Jun 2016 16:16:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-ID: <49D43DC03426A24BA76446434B4151EB@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7q+6x51HhBn1LpS2mbZ3KarF6+nc2 iw3XXrI6MHtsnDOdzWPJkp9MHk1njjIHMEdx2aSk5mSWpRbp2yVwZZy+d4ulYJF2ReP6J2wN jFO0uhg5OSQETCQm3fzIDGGLSVy4t56ti5GLQ0jgCKPEnwMtTBDOEkaJDUvXsIJUsQm4SDxo eMQEYosIqEtsXX0TyObgYAaKr9sVBmIKA4WvXEyFqNCQaDqzmAXCNpKYeWw2G4jNIqAqcXHL K7A4r4CFxPyea4wgtpCAlcTF7w2MIGM4Bawl5p9wAAkzAp32/dQasKXMAuISt57MZ4I4WUBi yZ7zUOeLSrx8/A/sSFEBPYkv9+aBjZEQUJKYtjUN4kZNifW79CGmWEu8/X6HBcJWlJjS/ZAd 4hhBiZMzn7BMYJSYhWTZLITuWUi6ZyHpnoWkewEj6ypG0eLU4uLcdCNjvdSizOTi4vw8vbzU kk2MwIg8uOW37g7G1a8dDzEKcDAq8fA+eBYZLsSaWFZcmXuIUYKDWUmE9/qjqHAh3pTEyqrU ovz4otKc1OJDjNIcLErivP4vFcOFBNITS1KzU1MLUotgskwcnFINjO6/Mo8YynkXlDyZ9HZ9 xyoP3YIeOc/HZnExx5c83sQht9HY6LXHUh3Hgm2l0+Ypev1eJGa80TE5oSAnXybS76B08RzN qiObGm072ENWnlUN2dr0q2fZ/meWHKYyceZcNXuWXGC0kRB32rOFfyvDwxDHG7KmV65JR33b Mken4SuTxiGLt//clFiKMxINtZiLihMBLu6n0MQCAAA= Archived-At: Cc: Justin Richer , "cose@ietf.org" Subject: Re: [COSE] WGLC, One more week 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 Jun 2016 16:16:10 -0000 T25seSBhIGZldyBjb21tZW50cywgYW5kIHdpdGggb25lIGV4Y2VwdGlvbiBvbmx5IGNvbW1lbnRz IG9uIHJlYWRhYmlsaXR5Lg0KDQpGb3Igc29tZW9uZSB0aGF0IGhhc24ndCBhIGNsdWUgd2hhdCB0 aGlzIGlzIGFib3V0LCB0aGUgZmlyc3QgZW5jb3VudGVyDQp3aXRoIHRoZSB0ZXJtICJDT1NFIiAo YXBhcnQgZnJvbSAiQ09TRSBXb3JraW5nIEdyb3VwIiBpbiB0aGUgaGVhZGVyIikgaXMNCmp1c3Qg YmVmb3JlIDEuMToNCg0KbyAiQ09TRSBpcyBub3QgYSBkaXJlY3QgY29weSBvZiB0aGUgSk9TRSBz cGVjaWZpY2F0aW9uLiAiDQoNCi0gSXQgd291bGQgYmUgbmljZSBpZiB0aGUgdGVybSAiQ09TRSIg d2FzIGZpcnN0IGRlZmluZWQgaW4gdGVybXMgb2Ygd2hhdA0KaXQgaXMsIHJhdGhlciB0aGFuIHdo YXQgaXQgaXMgbm90Lg0KDQotIFNob3VsZCB0aGUgdGVybSAiQ09TRSIgYmUgdXNlZCBpbmRlcGVu ZGVudGx5IGF0IGFsbCwgb3IgaW5zdGVhZCBhbHdheXMNCnRvZ2V0aGVyIHdpdGggc29tZSBub3Vu IGFzIGluICJDT1NFIE1lc3NhZ2UiLCAiY29zZSB0eXBlIiwgZXRjLj8NCg0KSW4gc2VjdGlvbiAy OyB0aXRsZSBpcyAiQmFzaWMgQ09TRSBTdHJ1Y3R1cmUiIGJ1dCBhcyBpcyBleHBsYWluZWQgaXQg aXMNCmFjdHVhbGx5IGFib3V0IHRoZSBDT1NFIE1lc3NhZ2Ugc3RydWN0dXJlLg0KDQpTaW1pbGFy bHkgaW4gc2VjdGlvbiAzIDoiVGhlIHN0cnVjdHVyZSBvZiBDT1NFIGhhcyBiZWVuIGRlc2lnbmVk IC4gLiAuIg0KDQpTZWN0aW9uIDIgdXNlcyB0aGUgdGVybSAiQ09TRSBvYmplY3TigJ0sIGlzIHRo YXQgZGlmZmVyZW50IGZyb20gIkNPU0UNCk1lc3NhZ2XigJ0/IChXaGVuIHJlZmVyZW5jaW5nIHRo ZSBjb25zdHJ1Y3RzIG9mIHRoaXMgZHJhZnQgd2UgY29uc2lzdGVudGx5DQp1c2VkIHRoZSB0ZXJt ICJDT1NFIG9iamVjdCIsIHNpbmNlIHRoZXJlIGlzIG9mdGVuIG90aGVyIGRhdGEgaW5jbHVkZWQg aW4NCnRoZSBhY3R1YWwgbWVzc2FnZSBiZWluZyBzZW50LikNCg0KDQpTZWN0aW9uIDQuMyANCg0K IlRoZSBwcmltYXJ5IHJlYXNvbiBmb3Igc3VwcG9ydGluZyB0aGlzIGNhbg0KYmUgc2VlbiBieSBs b29raW5nIGF0IHRoZSBDb0FQIG1lc3NhZ2Ugc3RydWN0dXJlIFtSRkM3MjUyXSB3aGVyZSB0aGUN CmZhY2lsaXR5IGV4aXN0cyBmb3Igb3B0aW9ucyB0byBiZSBjYXJyaWVkIGJlZm9yZSB0aGUgcGF5 bG9hZC4gQW4NCmV4YW1wbGUgb2YgZGF0YSB0aGF0IGNhbiBiZSBwbGFjZWQgaW4gdGhpcyBsb2Nh dGlvbiB3b3VsZCBiZSBDb0FQDQpvcHRpb25zIGZvciB0cmFuc2FjdGlvbiBpZHMgYW5kIG5vbmNl cyB0byBjaGVjayBmb3IgcmVwbGF5DQpwcm90ZWN0aW9uLiBJZiB0aGUgZGF0YSBpcyBpbiB0aGUg b3B0aW9ucyBzZWN0aW9uLCB0aGVuIGl0IGlzDQphdmFpbGFibGUgZm9yIHJvdXRlcnMgdG8gaGVs cCBpbiBwZXJmb3JtaW5nIHRoZSByZXBsYXkgZGV0ZWN0aW9uIGFuZA0KcHJldmVudGlvbi4gSG93 ZXZlciwgaXQgbWF5IGFsc28gYmUgZGVzaXJlZCB0byBwcm90ZWN0IHRoZXNlIHZhbHVlcw0Kc28g dGhhdCBpZiB0aGV5IGFyZSBiZSBtb2RpZmllZCBpbiB0cmFuc2l0IGl0IGNhbiBiZSBkZXRlY3Rl ZC7igJ0NCg0KVG8gbXkga25vd2xlZGdlLCB0aGVyZSBhcmUgbm8gcHJvcG9zZWQgQ29BUCBvcHRp b25zIGZvciB0cmFuc2FjdGlvbiBpZCBvcg0Kbm9uY2VzLCBhdCBsZWFzdCBub3Qgc3VjaCB0aGF0 IGFyZSBwcm9wb3NlZCB0byBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVkLCBidXQNCnRoZXJlIG1heSBi ZSBvdGhlciBDb0FQIG9wdGlvbnMgdGhhdCBuZWVkcyB0byBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVk IG9ubHkuDQoNCg0KDQpTZWN0aW9uIDUuMg0KDQoiVGhlIENPU0VfRW5jcnlwdDEgZW5jcnlwdGVk IHN0cnVjdHVyZSBkb2VzIG5vdCBoYXZlIHRoZSBhYmlsaXR5IHRvDQpzcGVjaWZ5IHJlY2lwaWVu dHMgb2YgdGhlIG1lc3NhZ2UuIFRoZSBzdHJ1Y3R1cmUgYXNzdW1lcyB0aGF0IHRoZQ0KcmVjaXBp ZW50IG9mIHRoZSBvYmplY3Qgd2lsbCBhbHJlYWR5IGtub3cgdGhlIGlkZW50aXR5IG9mIHRoZSBr ZXkgdG8NCmJlIHVzZWQgaW4gb3JkZXIgdG8gZGVjcnlwdCB0aGUgbWVzc2FnZS4gSWYgYSBrZXkg bmVlZHMgdG8gYmUNCmlkZW50aWZpZWQgdG8gdGhlIHJlY2lwaWVudCwgdGhlIGVudmVsb3BlZCBz dHJ1Y3R1cmUgb3VnaHQgdG8gYmUNCnVzZWQu4oCdDQoNCk9uZSB0eXBlIG9mIGNvbXBhY3QgZW5j cnlwdGlvbiBmb3JtYXRzIHdlIGhhdmUgbG9va2VkIGF0IGhhcyBiZWVuLA0KZXNzZW50aWFsbHk6 IFtrZXkgaWRlbnRpZmllciwgY2lwaGVyIHRleHRdIChkaXNyZWdhcmRpbmcgSVYgZXRjLikuIFdl DQp3b3VsZCBsaWtlIHRvIHVzZSBDT1NFX0VuY3J5cHQxIHdoaWNoIGVzc2VudGlhbGx5IGlzOiBb YWxnb3JpdGhtLCBjaXBoZXINCnRleHRdIChkaXNyZWdhcmRpbmcgSVYgZXRjLikuIE1ha2luZyBh bGdvcml0aG0gb3B0aW9uYWwgaXMgY292ZXJlZCBpbg0KQXBwZW5kaXggQS4gQnV0IEkgcmVhZCB0 aGUgdGV4dCBhYm92ZSBhcyB1c2luZyB0aGlzIGZvcm1hdCB3aXRoIGEga2lkDQpoZWFkZXIgaXMg bm90IHBvc3NpYmxlLCBpcyB0aGF0IHRoZSBpbnRlbnRpb24/IEkgY2FuIG1heWJlIHVuZGVyc3Rh bmQgdGhpcw0KZnJvbSBhIGxldmVsL2xheWVyIHN0cnVjdHVyZSBwb2ludCBvZiwgYnV0IG5vdCBy ZWFsbHkgZnJvbSBhIHNlY3VyaXR5DQpwb2ludCBvZiB2aWV3LiANCg0KDQpTZWN0aW9uIDEyLjQu MSwgbmV3IGJ1bGxldCBpcyBmaW5lLCBmb3Jnb3QgdG8gYWNrbm93bGVkZ2UgdGhhdC4NCg0KDQpB cHBlbmRpeCBCIGluIHBhcnRpY3VsYXIsIGJ1dCBhbHNvIG90aGVyIHBhcnRzIHNwZWFrIG9mIOKA nGxldmVsc+KAnSBhbmQNCuKAnGxheWVyc+KAnSwgd2hpY2ggc2VlbXMgbGlrZSBzeW5vbnltcywg b3IgaXMgdGhlcmUgYSBkaWZmZXJlbmNlPw0KDQoNCkfDtnJhbg0KDQoNCg0KDQoNCk9uIDIwMTYt MDYtMDQgMDI6NTEsICJDT1NFIG9uIGJlaGFsZiBvZiBKdXN0aW4gUmljaGVyIg0KPGNvc2UtYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YganJpY2hlckBtaXQuZWR1PiB3cm90ZToNCg0KPkhp IGV2ZXJ5b25lLA0KPg0KPkp1c3QgYSBnZW50bGUgcmVtaW5kZXIgdGhhdCB0aGUgV0dMQyBvbiB0 aGUgQ09TRSBNZXNzYWdlcyBkcmFmdCBjbG9zZXMgYQ0KPndlZWsgZnJvbSB0b2RheSwgb24gSnVu ZSAxMCAyMDE2LiBEdWUgdG8gdGltZXpvbmVzLCBzY2hlZHVsZXMsIGFuZCB0aGUNCj5ibGFjayBh cnQgb2YgU01UUCBkZWxpdmVyeSwgd2UgY2FuJ3QgZ3VhcmFudGVlIGFueSBwYXJ0aWN1bGFyIHRp bWUNCj5kdXJpbmcgdGhlIGRheSB0aGF0IHRoZSBjYWxsIHdpbGwgY2xvc2UuIFRoZXJlZm9yZSwg aWYgeW91J3ZlIGdvdA0KPnNvbWV0aGluZyB0byBzYXkgYWJvdXQgdGhlIGRyYWZ0LCBwbGVhc2Ug ZG8gc28gZWFybGllciBpbiB0aGUgd2Vlaw0KPnJhdGhlciB0aGFuIGxhdGVyLiBObyB0aW1lIGxp a2UgdGhlIHByZXNlbnQhDQo+DQo+VGhlIGxhdGVzdCBkcmFmdCAoMTIpIGlzIGhlcmU6DQo+DQo+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29zZS1tc2ctMTINCj4NCj5U aGUgaXNzdWUgdHJhY2tlciBpcyBoZXJlIChidXQgd2UnZCBwcmVmZXIgY29tbWVudHMgdG8gdGhl IGxpc3QgaW4gdGhpcw0KPnBlcmlvZCk6DQo+DQo+aHR0cHM6Ly9naXRodWIuY29tL2Nvc2Utd2cv Y29zZS1pc3N1ZXMvaXNzdWVzDQo+DQo+UGxlYXNlIHJlYWQgYW5kIHJldmlldywgYW5kIHdlJ3Jl IGV2ZW4gbG9va2luZyBmb3IgInl1cCwgaXQgbG9va3MgZ29vZA0KPnRvIG1lIiBmcm9tIHBlb3Bs ZSBpZiB0aGF0J3MgeW91ciB0YWtlIG9uIHRoaW5ncy4NCj4NCj5UaGFua3MgZXZlcnlvbmUsDQo+ DQo+ICAtLSBKdXN0aW4sIHlvdXIgQ09TRSBjaGFpcg0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Q09TRSBtYWlsaW5nIGxpc3QNCj5DT1NFQGll dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQoNCg== From nobody Fri Jun 10 13:11:25 2016 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 B4A66128B44 for ; Fri, 10 Jun 2016 13:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 4XW24ha7XflU for ; Fri, 10 Jun 2016 13:11:20 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE53212D913 for ; Fri, 10 Jun 2016 13:11:18 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 5675438F06; Fri, 10 Jun 2016 13:11:18 -0700 (PDT) From: "Jim Schaad" To: "'Carsten Bormann'" , References: <575A6ACE.7040808@tzi.org> In-Reply-To: <575A6ACE.7040808@tzi.org> Date: Fri, 10 Jun 2016 13:11:17 -0700 Message-ID: <072501d1c354$3fb17a40$bf146ec0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFs9xo6Aem0Yt+tzKW6jT1YcfgpRqCsnBBg Content-Language: en-us Archived-At: Subject: Re: [COSE] PartyInfo 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 Jun 2016 20:11:23 -0000 Carsten, I went around on this several times and ended up deciding that it was = not necessary to have the nils in these locations. It took me a bit to = reconstruct my reasoning but here it is. The most important thing about this structure is that one needs to = ensure that both sides will produce the same string of bytes so that = they can get the same result in the end. If one looks at this criteria, = then the nils are not needed at all as the order of items is going to be = the only significant thing to be considered.=20 This means that an attacker could, potentially, change the tag on a = transported field but the order of fields can still be same and the = resulting structure would be the same. Note that one cannot combine two = different fields together as the CBOR encoding provides a length for = each of the bstr or int elements. This means that the number of items = that must be extant cannot be changed either. So the question is can one mount an attack by changing the tag on a = label? =20 This cannot happen if the fields content is specified by the application = protocol. I.e. if the content of the identify field is a constant = defined by the application then it cannot be shifted by an attacker if = it is not transported. And it would need to be of a specific value or = form if it were to be transported. =20 If I specify a nonce and send a message, it gets moved to the identify = field and no other identify field is going to be specified by the = application. Then you would end up with the same value at the end. = However, if the application has specified that the identity or field is = to be used in some specific manner, the resulting set of fields would = not be of the correct form or would not be available to be used = correctly. Two examples, if the nonce was moved it would not be available to be = used in a response message were the application to say that the partyU = nonce is moved to the partyV nonce in the return message. If the = identity field is used as part of the trust decision, a value moved from = the nonce field. Then the identity is unlikely to be of a valid form as = input to the trust decision and thus there would be a failure at a later = point. In short, I don't believe that we need to fill in the space where one of = these fields is not present as I have not been able to see how it will = be usable as realistic attack vector. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Friday, June 10, 2016 12:23 AM > To: cose@ietf.org > Subject: [COSE] PartyInfo >=20 > Maybe a minor nit, but shouldn't be >=20 > PartyInfo =3D ( > ? nonce : bstr / int, > ? identity : bstr, > ? other : bstr, > ) >=20 > better be done as >=20 > PartyInfo =3D ( > nonce : bstr / int / nil, > identity : bstr / nil, > ? other : bstr, > ) >=20 > (This is used in an array context, so any non-final optionals create a = potential for > mixup.) >=20 > While the attack surface of any confusion that can be created here is = rather > small, I don't think we have to "save those bytes". >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > PS.: Yes, this could also be done as: >=20 >=20 > PartyInfo =3D ( > nonce : bstr / int / nil, > ? (identity : bstr / nil, > ? other : bstr), > ) >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Fri Jun 10 13:30:40 2016 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 3FFB012D561 for ; Fri, 10 Jun 2016 13:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 unmbLmsZfFuF for ; Fri, 10 Jun 2016 13:30:36 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2B312B031 for ; Fri, 10 Jun 2016 13:30:36 -0700 (PDT) Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 970F4A80BE; Fri, 10 Jun 2016 22:30:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter17-d.gandi.net (mfilter17-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id tASHesHUSZCc; Fri, 10 Jun 2016 22:30:33 +0200 (CEST) X-Originating-IP: 134.102.91.56 Received: from eduroam-pool10-313.wlan.uni-bremen.de (eduroam-pool10-313.wlan.uni-bremen.de [134.102.91.56]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 93750A80C6; Fri, 10 Jun 2016 22:30:32 +0200 (CEST) Message-ID: <575B2366.3010504@tzi.org> Date: Fri, 10 Jun 2016 22:30:30 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Jim Schaad References: <575A6ACE.7040808@tzi.org> <072501d1c354$3fb17a40$bf146ec0$@augustcellars.com> In-Reply-To: <072501d1c354$3fb17a40$bf146ec0$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] PartyInfo 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 Jun 2016 20:30:38 -0000 Jim Schaad wrote: > In short, I don't believe that we need to fill in the space where one of these fields is not present as I have not been able to see how it will be usable as realistic attack vector. I agree that this is a bit far-fetched. As I said, I don't know how to construct an attack either, but as a matter of principle I wouldn't build something that even provides a potential for, say, an attacker-provided nonce turning up as if it were a party identifier. And, the cost of "fixing" this is quite limited. (But I'm not insisting on anything here.) Grüße, Carsten From nobody Fri Jun 10 16:18:04 2016 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 A053512D568 for ; Fri, 10 Jun 2016 16:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 lrFGhMn32I5a for ; Fri, 10 Jun 2016 16:18:01 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C5712D536 for ; Fri, 10 Jun 2016 16:18:01 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 71D5638F5B; Fri, 10 Jun 2016 16:18:00 -0700 (PDT) From: "Jim Schaad" To: =?UTF-8?Q?'G=C3=B6ran_Selander'?= References: In-Reply-To: Date: Fri, 10 Jun 2016 16:17:59 -0700 Message-ID: <073401d1c36e$54e41e30$feac5a90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIpPzywWYU+9lbmJceVi3vGPxt34wJTUoRJnyGPh7A= Content-Language: en-us Archived-At: Cc: 'Justin Richer' , cose@ietf.org Subject: Re: [COSE] WGLC, One more week 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 Jun 2016 23:18:03 -0000 Just this last week I ended up in a situation where somebody used an = acronym that I did not understand that highlights one of your points = below. Somebody was asking me questions about CEMS and I did not = understand until some ways into the conversation that they were = referring to "CBOR Encoded Message Syntax".=20 I am reluctant to use CEMS as a short hand for this, in part because it = is just too close to CMS and I personally don't want to get confused = between the two different specifications when people start asking me = questions out of the blue. I have been using the term COSE to refer to this work as a single entity = without trying to differentiate between the different structures as JOSE = did with the JWS, JWE, JWK, JWE. It is not clear if they use the term = JOSE for the overall set of specs within their community or not. I know = that I frequently will use it myself when I talk to people. =20 I would like to promulgate the use of COSE as the short hand term for = this specification and the follow on work done just like CMS is used for = that set of specifications. For that reason, I would like to keep the = current set of references to COSE as an item rather than using it as a = modifier. I do however think that I need to change the title of the = document to make this work. How do people feel about a new title of = "COSE: An encryption and signing solution for CBOR". Other notes inline Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of G=C3=B6ran = Selander > Sent: Friday, June 10, 2016 9:16 AM > To: Jim Schaad > Cc: Justin Richer ; cose@ietf.org > Subject: Re: [COSE] WGLC, One more week >=20 > Only a few comments, and with one exception only comments on = readability. >=20 > For someone that hasn't a clue what this is about, the first encounter = with the > term "COSE" (apart from "COSE Working Group" in the header") is just = before > 1.1: It is now defined in the introduction. >=20 > o "COSE is not a direct copy of the JOSE specification. " >=20 > - It would be nice if the term "COSE" was first defined in terms of = what it is, > rather than what it is not. >=20 > - Should the term "COSE" be used independently at all, or instead = always > together with some noun as in "COSE Message", "cose type", etc.? >=20 > In section 2; title is "Basic COSE Structure" but as is explained it = is actually about > the COSE Message structure. >=20 > Similarly in section 3 :"The structure of COSE has been designed . . = ." >=20 > Section 2 uses the term "COSE object=E2=80=9D, is that different from = "COSE Message=E2=80=9D? > (When referencing the constructs of this draft we consistently used = the term > "COSE object", since there is often other data included in the actual = message > being sent.) I switch to using COSE object everywhere. =20 >=20 >=20 > Section 4.3 >=20 > "The primary reason for supporting this can be seen by looking at the = CoAP > message structure [RFC7252] where the facility exists for options to = be carried > before the payload. An example of data that can be placed in this = location would > be CoAP options for transaction ids and nonces to check for replay = protection. If > the data is in the options section, then it is available for routers = to help in > performing the replay detection and prevention. However, it may also = be > desired to protect these values so that if they are be modified in = transit it can be > detected.=E2=80=9D >=20 > To my knowledge, there are no proposed CoAP options for transaction id = or > nonces, at least not such that are proposed to be integrity protected, = but there > may be other CoAP options that needs to be integrity protected only. I have done a re-write on this >=20 >=20 >=20 > Section 5.2 >=20 > "The COSE_Encrypt1 encrypted structure does not have the ability to = specify > recipients of the message. The structure assumes that the recipient of = the object > will already know the identity of the key to be used in order to = decrypt the > message. If a key needs to be identified to the recipient, the = enveloped structure > ought to be used.=E2=80=9D >=20 > One type of compact encryption formats we have looked at has been, > essentially: [key identifier, cipher text] (disregarding IV etc.). We = would like to > use COSE_Encrypt1 which essentially is: [algorithm, cipher text] = (disregarding IV > etc.). Making algorithm optional is covered in Appendix A. But I read = the text > above as using this format with a kid header is not possible, is that = the intention? > I can maybe understand this from a level/layer structure point of, but = not really > from a security point of view. The choice of the word 'ought' was very deliberate. The intention is to = say that this is what it is believed should be done, but it is not by = any means a statement of requirement. You can violate this without = being in violation of the rules, but you should really think about why = you are doing it. >=20 >=20 > Section 12.4.1, new bullet is fine, forgot to acknowledge that. >=20 >=20 > Appendix B in particular, but also other parts speak of = =E2=80=9Clevels=E2=80=9D and =E2=80=9Clayers=E2=80=9D, > which seems like synonyms, or is there a difference? No they are the same thing. I have harmonized to layers. Jim >=20 >=20 > G=C3=B6ran >=20 >=20 >=20 >=20 >=20 > On 2016-06-04 02:51, "COSE on behalf of Justin Richer" > wrote: >=20 > >Hi everyone, > > > >Just a gentle reminder that the WGLC on the COSE Messages draft = closes > >a week from today, on June 10 2016. Due to timezones, schedules, and > >the black art of SMTP delivery, we can't guarantee any particular = time > >during the day that the call will close. Therefore, if you've got > >something to say about the draft, please do so earlier in the week > >rather than later. No time like the present! > > > >The latest draft (12) is here: > > > >https://tools.ietf.org/html/draft-ietf-cose-msg-12 > > > >The issue tracker is here (but we'd prefer comments to the list in = this > >period): > > > >https://github.com/cose-wg/cose-issues/issues > > > >Please read and review, and we're even looking for "yup, it looks = good > >to me" from people if that's your take on things. > > > >Thanks everyone, > > > > -- Justin, your COSE chair > > > >_______________________________________________ > >COSE mailing list > >COSE@ietf.org > >https://www.ietf.org/mailman/listinfo/cose >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Fri Jun 10 16:47:32 2016 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 DC7E112D5F0 for ; Fri, 10 Jun 2016 16:47:30 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 cG0skul-Wkye for ; Fri, 10 Jun 2016 16:47:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C83C12DA00 for ; Fri, 10 Jun 2016 16:47:27 -0700 (PDT) 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=n7TWXRPER6W6q5fPJ/9KIZ4H90zzibkX5Zsze4Awhzg=; b=E3qhVzb1z2gH+IkDZGZUsGFSu4e5Y/YT7F4AIoYZ+PPS5HAgQI0+S8zEY+RY41NVHqdNIcsOoqk5f+xGMTLFI186SZIpRGjhcCVAuufG81yFS50GDZXt98IXDcq36bY9WODLi7vXi22L3bvOMpu0ptJpmQ0ZPndzOZpbfC+YouM= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1646.namprd03.prod.outlook.com (10.162.130.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Fri, 10 Jun 2016 23:47:11 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0517.005; Fri, 10 Jun 2016 23:47:11 +0000 From: Mike Jones To: Jim Schaad , =?Windows-1252?Q?=27G=F6ran_Selander=27?= Thread-Topic: [COSE] WGLC, One more week Thread-Index: AQHRvftKB9od3a5J0UK317au9KDmm5/i6tCAgAB14ICAAAgp/g== Date: Fri, 10 Jun 2016 23:47:11 +0000 Message-ID: References: , <073401d1c36e$54e41e30$feac5a90$@augustcellars.com> In-Reply-To: <073401d1c36e$54e41e30$feac5a90$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [166.177.122.174] x-ms-office365-filtering-correlation-id: 0f65146e-7a18-4f7f-918d-08d391898ac7 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1646; 6:vbXpaSPHbo16JFuGrISvi5LA1/bcij1rogl5BG9OqZweEi+XAC6wxN7BRPUEmO5ERXKNSyCrQyK1w8Xmv4BAMJDJE7gvJkpkCm122AlwlpEEDOQSwe5Y3RpxvLXDsV7ra/W5pclLwXNwEqbkhxtwhPCddlQEi/YbIC3e9KtD5+a9z49q0x/MjgO6U5ABMAqxJk77KBmeZSH5i8zSv/i8qi5MFLNFj6dF9tqf8sV2oTkbBLHRzW20/d5pFixQMCW0y5jRpxJYQTtcdheQsTkQQSs42SiVYZ+b2hRJQEj/KYSj31HiOX+hE36lICUJUiq0E2V4dx7JzPxAfjZwIHJHnw==; 5:AinniwZIbjrch5hgNR6g1CQYrn3+K30shY9uVSATlwvSiIoItXrRsiitNgD/gswRWPgSnZWl0V3e/kEMG1F7JVQRiQteFj+BhyWQe6r+UZyEY8fjpLnKO+0/xOX5CvWZrQ/+jfjiEg14nhXCzGyAFQ==; 24:IY7yDfVqOn330xVtubupp08O575rfpw/6dw6v1LPWpn9lIIkBL8+zJc/KSBk6T4rPWEmsPhRuaRvOHYNWrePfpRsZBaEZ7rpi4lastzYc9s=; 7:o9ZrncjasSnciT1oxYAg8GBWYml50N3smgFr1L1E5Ve2E94aED4bbDS76vOt60u7rSo5GQ+ZbUC7PORNj8IeV0LUNgwAe+xOGckTKtzhSFgsFd5+bipamLA1OQ+CQNJWcG5J7Yil+ENDL+5s0jKB6eCURJ9XbYFi+FwP3DGwMHb94bNDw3upgVulI3+ci200W7On0ihKC5nqlbEP7Xpjc/E/1j2L7NtyZtsArJoMcnbcCw87C7fdyjIx9uulhyAF x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(166708455590820)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1646; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1646; x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(189002)(199003)(53754006)(377424004)(13464003)(52024003)(9686002)(4326007)(3660700001)(81156014)(76576001)(81166006)(11100500001)(2950100001)(101416001)(2906002)(8676002)(87936001)(15975445007)(5004730100002)(551934003)(122556002)(74316001)(8936002)(102836003)(86612001)(50986999)(2900100001)(3846002)(6116002)(3280700002)(586003)(68736007)(76176999)(10290500002)(54356999)(77096005)(19580395003)(5005710100001)(106356001)(8990500004)(10400500002)(19580405001)(5003600100002)(66066001)(5008740100001)(5002640100001)(105586002)(106116001)(10090500001)(99286002)(16236675004)(5001770100001)(97736004)(19617315012)(19625215002)(33656002)(3900700001)(92566002)(86362001)(189998001)(7906002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1646; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16454F1CE135FF9F2CE7BED2F5500SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2016 23:47:11.2377 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1646 Archived-At: Cc: 'Justin Richer' , "cose@ietf.org" Subject: Re: [COSE] WGLC, One more week 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 Jun 2016 23:47:31 -0000 --_000_SN1PR0301MB16454F1CE135FF9F2CE7BED2F5500SN1PR0301MB1645_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Why not just the title CBOR Object Signing and Encryption (COSE)? Then the= title and acronym would match. =96 Mike From: Jim Schaad Sent: Friday, June 10, 2016 6:18 PM To: 'G=F6ran Selander' Cc: 'Justin Richer'; cose@ietf.org Subject: Re: [COSE] WGLC, One more week Just this last week I ended up in a situation where somebody used an acrony= m that I did not understand that highlights one of your points below. Some= body was asking me questions about CEMS and I did not understand until some= ways into the conversation that they were referring to "CBOR Encoded Messa= ge Syntax". I am reluctant to use CEMS as a short hand for this, in part because it is = just too close to CMS and I personally don't want to get confused between t= he two different specifications when people start asking me questions out o= f the blue. I have been using the term COSE to refer to this work as a single entity wi= thout trying to differentiate between the different structures as JOSE did = with the JWS, JWE, JWK, JWE. It is not clear if they use the term JOSE for= the overall set of specs within their community or not. I know that I fre= quently will use it myself when I talk to people. I would like to promulgate the use of COSE as the short hand term for this = specification and the follow on work done just like CMS is used for that se= t of specifications. For that reason, I would like to keep the current set= of references to COSE as an item rather than using it as a modifier. I do= however think that I need to change the title of the document to make this= work. How do people feel about a new title of "COSE: An encryption and si= gning solution for CBOR". Other notes inline Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of G=F6ran Selander > Sent: Friday, June 10, 2016 9:16 AM > To: Jim Schaad > Cc: Justin Richer ; cose@ietf.org > Subject: Re: [COSE] WGLC, One more week > > Only a few comments, and with one exception only comments on readability. > > For someone that hasn't a clue what this is about, the first encounter wi= th the > term "COSE" (apart from "COSE Working Group" in the header") is just befo= re > 1.1: It is now defined in the introduction. > > o "COSE is not a direct copy of the JOSE specification. " > > - It would be nice if the term "COSE" was first defined in terms of what = it is, > rather than what it is not. > > - Should the term "COSE" be used independently at all, or instead always > together with some noun as in "COSE Message", "cose type", etc.? > > In section 2; title is "Basic COSE Structure" but as is explained it is a= ctually about > the COSE Message structure. > > Similarly in section 3 :"The structure of COSE has been designed . . ." > > Section 2 uses the term "COSE object=94, is that different from "COSE Mes= sage=94? > (When referencing the constructs of this draft we consistently used the t= erm > "COSE object", since there is often other data included in the actual mes= sage > being sent.) I switch to using COSE object everywhere. > > > Section 4.3 > > "The primary reason for supporting this can be seen by looking at the CoA= P > message structure [RFC7252] where the facility exists for options to be c= arried > before the payload. An example of data that can be placed in this locatio= n would > be CoAP options for transaction ids and nonces to check for replay protec= tion. If > the data is in the options section, then it is available for routers to h= elp in > performing the replay detection and prevention. However, it may also be > desired to protect these values so that if they are be modified in transi= t it can be > detected.=94 > > To my knowledge, there are no proposed CoAP options for transaction id or > nonces, at least not such that are proposed to be integrity protected, bu= t there > may be other CoAP options that needs to be integrity protected only. I have done a re-write on this > > > > Section 5.2 > > "The COSE_Encrypt1 encrypted structure does not have the ability to speci= fy > recipients of the message. The structure assumes that the recipient of th= e object > will already know the identity of the key to be used in order to decrypt = the > message. If a key needs to be identified to the recipient, the enveloped = structure > ought to be used.=94 > > One type of compact encryption formats we have looked at has been, > essentially: [key identifier, cipher text] (disregarding IV etc.). We wou= ld like to > use COSE_Encrypt1 which essentially is: [algorithm, cipher text] (disrega= rding IV > etc.). Making algorithm optional is covered in Appendix A. But I read the= text > above as using this format with a kid header is not possible, is that the= intention? > I can maybe understand this from a level/layer structure point of, but no= t really > from a security point of view. The choice of the word 'ought' was very deliberate. The intention is to sa= y that this is what it is believed should be done, but it is not by any mea= ns a statement of requirement. You can violate this without being in viola= tion of the rules, but you should really think about why you are doing it. > > > Section 12.4.1, new bullet is fine, forgot to acknowledge that. > > > Appendix B in particular, but also other parts speak of =93levels=94 and = =93layers=94, > which seems like synonyms, or is there a difference? No they are the same thing. I have harmonized to layers. Jim > > > G=F6ran > > > > > > On 2016-06-04 02:51, "COSE on behalf of Justin Richer" > wrote: > > >Hi everyone, > > > >Just a gentle reminder that the WGLC on the COSE Messages draft closes > >a week from today, on June 10 2016. Due to timezones, schedules, and > >the black art of SMTP delivery, we can't guarantee any particular time > >during the day that the call will close. Therefore, if you've got > >something to say about the draft, please do so earlier in the week > >rather than later. No time like the present! > > > >The latest draft (12) is here: > > > >https://tools.ietf.org/html/draft-ietf-cose-msg-12 > > > >The issue tracker is here (but we'd prefer comments to the list in this > >period): > > > >https://github.com/cose-wg/cose-issues/issues > > > >Please read and review, and we're even looking for "yup, it looks good > >to me" from people if that's your take on things. > > > >Thanks everyone, > > > > -- Justin, your COSE chair > > > >_______________________________________________ > >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 _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose --_000_SN1PR0301MB16454F1CE135FF9F2CE7BED2F5500SN1PR0301MB1645_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Why not just the title CBOR Object Signing and Enc= ryption (COSE)?  Then the title and acronym would match.

 

=96 Mike

 

 

From: Jim Schaad
Sent: Friday, June 10, 2016 6:18 PM
To: 'G=F6ran Selander= '
Cc: 'Justin Richer'; cose@ietf.org
Subject: Re: [COSE] WGLC, One more week

 

Just this last week I ended up in a situation wher= e somebody used an acronym that I did not understand that highlights one of= your points below.  Somebody was asking me questions about CEMS and I= did not understand until some ways into the conversation that they were referring to "CBOR Encoded Message Sy= ntax".

I am reluctant to use CEMS as a short hand for this, in part because it is = just too close to CMS and I personally don't want to get confused between t= he two different specifications when people start asking me questions out o= f the blue.

I have been using the term COSE to refer to this work as a single entity wi= thout trying to differentiate between the different structures as JOSE did = with the JWS, JWE, JWK, JWE.  It is not clear if they use the term JOS= E for the overall set of specs within their community or not.  I know that I frequently will use it myself = when I talk to people. 

I would like to promulgate the use of COSE as the short hand term for this = specification and the follow on work done just like CMS is used for that se= t of specifications.  For that reason, I would like to keep the curren= t set of references to COSE as an item rather than using it as a modifier.  I do however think that I need t= o change the title of the document to make this work.  How do people f= eel about a new title of "COSE: An encryption and signing solution for= CBOR".

Other notes inline

Jim


> -----Original Message-----
> From: COSE [mailto:cose-bounc= es@ietf.org] On Behalf Of G=F6ran Selander
> Sent: Friday, June 10, 2016 9:16 AM
> To: Jim Schaad <ietf@augustcellars.com>
> Cc: Justin Richer <jricher@mit.edu>; cose@ietf.org
> Subject: Re: [COSE] WGLC, One more week
>
> Only a few comments, and with one exception only comments on readabili= ty.
>
> For someone that hasn't a clue what this is about, the first encounter= with the
> term "COSE" (apart from "COSE Working Group" in th= e header") is just before
> 1.1:

It is now defined in the introduction.

>
> o "COSE is not a direct copy of the JOSE specification. " >
> - It would be nice if the term "COSE" was first defined in t= erms of what it is,
> rather than what it is not.
>
> - Should the term "COSE" be used independently at all, or in= stead always
> together with some noun as in "COSE Message", "cose typ= e", etc.?
>
> In section 2; title is "Basic COSE Structure" but as is expl= ained it is actually about
> the COSE Message structure.
>
> Similarly in section 3 :"The structure of COSE has been designed = . . ."
>
> Section 2 uses the term "COSE object=94, is that different from &= quot;COSE Message=94?
> (When referencing the constructs of this draft we consistently used th= e term
> "COSE object", since there is often other data included in t= he actual message
> being sent.)

I switch to using COSE object everywhere. 

>
>
> Section 4.3
>
> "The primary reason for supporting this can be seen by looking at= the CoAP
> message structure [RFC7252] where the facility exists for options to b= e carried
> before the payload. An example of data that can be placed in this loca= tion would
> be CoAP options for transaction ids and nonces to check for replay pro= tection. If
> the data is in the options section, then it is available for routers t= o help in
> performing the replay detection and prevention. However, it may also b= e
> desired to protect these values so that if they are be modified in tra= nsit it can be
> detected.=94
>
> To my knowledge, there are no proposed CoAP options for transaction id= or
> nonces, at least not such that are proposed to be integrity protected,= but there
> may be other CoAP options that needs to be integrity protected only.
I have done a re-write on this

>
>
>
> Section 5.2
>
> "The COSE_Encrypt1 encrypted structure does not have the ability = to specify
> recipients of the message. The structure assumes that the recipient of= the object
> will already know the identity of the key to be used in order to decry= pt the
> message. If a key needs to be identified to the recipient, the envelop= ed structure
> ought to be used.=94
>
> One type of compact encryption formats we have looked at has been,
> essentially: [key identifier, cipher text] (disregarding IV etc.). We = would like to
> use COSE_Encrypt1 which essentially is: [algorithm, cipher text] (disr= egarding IV
> etc.). Making algorithm optional is covered in Appendix A. But I read = the text
> above as using this format with a kid header is not possible, is that = the intention?
> I can maybe understand this from a level/layer structure point of, but= not really
> from a security point of view.

The choice of the word 'ought' was very deliberate.  The intention is = to say that this is what it is believed should be done, but it is not by an= y means a statement of requirement.  You can violate this without bein= g in violation of the rules, but you should really think about why you are doing it.

>
>
> Section 12.4.1, new bullet is fine, forgot to acknowledge that.
>
>
> Appendix B in particular, but also other parts speak of =93levels=94 a= nd =93layers=94,
> which seems like synonyms, or is there a difference?

No they are the same thing.  I have harmonized to layers.

Jim

>
>
> G=F6ran
>
>
>
>
>
> On 2016-06-04 02:51, "COSE on behalf of Justin Richer"
> <cose-bounces@ietf.org on behalf of jricher@mit.edu> wrote:
>
> >Hi everyone,
> >
> >Just a gentle reminder that the WGLC on the COSE Messages draft cl= oses
> >a week from today, on June 10 2016. Due to timezones, schedules, a= nd
> >the black art of SMTP delivery, we can't guarantee any particular = time
> >during the day that the call will close. Therefore, if you've got<= br> > >something to say about the draft, please do so earlier in the week=
> >rather than later. No time like the present!
> >
> >The latest draft (12) is here:
> >
> >htt= ps://tools.ietf.org/html/draft-ietf-cose-msg-12
> >
> >The issue tracker is here (but we'd prefer comments to the list in= this
> >period):
> >
> >https://= github.com/cose-wg/cose-issues/issues
> >
> >Please read and review, and we're even looking for "yup, it l= ooks good
> >to me" from people if that's your take on things.
> >
> >Thanks everyone,
> >
> >  -- Justin, your COSE chair
> >
> >_______________________________________________
> >COSE mailing list
> >COSE@ietf.org
> >https://www= .ietf.org/mailman/listinfo/cose
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.iet= f.org/mailman/listinfo/cose

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org= /mailman/listinfo/cose
 --_000_SN1PR0301MB16454F1CE135FF9F2CE7BED2F5500SN1PR0301MB1645_-- From nobody Fri Jun 10 17:08:44 2016 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 AA59912D09A for ; Fri, 10 Jun 2016 17:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SUBJ_AS_SEEN=1.461] autolearn=no 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 9-8v61Tkp1tc for ; Fri, 10 Jun 2016 17:08:41 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C2112D68A for ; Fri, 10 Jun 2016 17:08:41 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 4037E2CA09; Fri, 10 Jun 2016 17:08:41 -0700 (PDT) From: "Jim Schaad" To: "'Carsten Bormann'" , References: <575A7F96.4080102@tzi.org> In-Reply-To: <575A7F96.4080102@tzi.org> Date: Fri, 10 Jun 2016 17:08:40 -0700 Message-ID: <074901d1c375$69235c10$3b6a1430$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEgEfqZTeAm5nmJGehzRxqWtxIvIqFGxqYA Content-Language: en-us Archived-At: Subject: Re: [COSE] COSE as seen by a bunch of students 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, 11 Jun 2016 00:08:43 -0000 This would appear to mean that the document was understandable to a = group of people with minimal familiarity however. I find that = encouraging as the author. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Friday, June 10, 2016 1:52 AM > To: cose@ietf.org > Subject: [COSE] COSE as seen by a bunch of students >=20 > Not quite a WGLC review, but here's what a group of students had to = say about > draft-ietf-cose-msg-12.txt as part of a recent class assignment (with = permission, > excerpted and translated by yours truly). >=20 > (Please don't read this as a criticism of CMS, the students just = happened to need > to look at both CMS and COSE for the assignment.) >=20 > My main point here is that the -msg draft indeed appears to be quite = accessible > for new people to acquaint themselves with COSE, and I'm happy to see = that we > seem to have achieved that. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > ... > The COSE draft provides current encryption algorithms and hashes = (EdDSA, SHA- > 2, AES, ChaCha20/Poly1305, ECDH). > It is prepared for the future by using IANA for defining and = publishing identifiers > for new algorithms, so that the relevant algorithms can all be found = in one > place. > ... > Since COSE is based on CBOR, some information can be expressed in a = more > compact and simple way [than with CMS]. > A single CBOR parser can be used for all formats. > In addition, all formats have a very similar structure that is sharing = the header: > an array containing two headers with meta information as well as a = field for > payloads and optional fields for signatures and recipients. > COSE has been developed for the use on devices with constrained = resources, so > the parsing of the packets should use minimal time, energy and memory. > ... > [In comparing CMS and COSE:] > There is no equivalent [in COSE] for the Digested-data Content Type = [in CMS]. > ... > In reading the available source documents it became apparent that the = COSE > draft places a lot more attention on examples and howto's, making the = draft > much more readable. ASN.1 is getting in the way of understanding, = CBOR is > easier to understand. Also, there are no test vectors in the CMS RFCs = we used. >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Sun Jun 12 12:59:05 2016 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 1DC3312B038 for ; Sun, 12 Jun 2016 12:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SUBJ_ALL_CAPS=1.506] autolearn=no 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 CJX1G5jkeehd for ; Sun, 12 Jun 2016 12:59:01 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A78BA12D130 for ; Sun, 12 Jun 2016 12:59:01 -0700 (PDT) Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 2926CA80C0; Sun, 12 Jun 2016 21:59:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id FRXxlwL9MmNH; Sun, 12 Jun 2016 21:58:58 +0200 (CEST) X-Originating-IP: 193.1.66.157 Received: from nar-3.local (unknown [193.1.66.157]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id CD045A80C8; Sun, 12 Jun 2016 21:58:57 +0200 (CEST) Message-ID: <575DBF01.3050608@tzi.org> Date: Sun, 12 Jun 2016 20:58:57 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Justin Richer References: <87B21730-AD6A-4D00-AEBB-72E78A55B6C8@mit.edu> <575842B6.5070401@tzi.org> In-Reply-To: <575842B6.5070401@tzi.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: cose Subject: Re: [COSE] WGLC 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: Sun, 12 Jun 2016 19:59:03 -0000 Carsten Bormann wrote: > expect my full review Below. This was one of the better drafts I have reviewed in my IETF life. Grüße, Carsten The COSE message syntax draft is mostly ready to implement. Some further editorial work could improve the document. (Pull request #158 contains some typos and other trivial editorial improvements.) # Process 8.2 Are we creating a dependency here on a document that might take forever to complete? Maybe mark this section with a "Sollbruchstelle" (~ toilet paper perforation), so it can be detached into a separate document if that happens. # Technical 2. second item list, item 3/4. The media type system REST adopted from MIME is represented by the Content-Type header field in HTTP and the Content-Format (!) Option in CoAP. (The latter also covers what is Content-Encoding in HTTP.) Editorial: The text here is about media types, and only then about how these are represented in the REST protocols. Technical: CoAP Content-Formats are represented by unsigned integers, not integers in general (fix header parameter 3, content type). Related in 3.1: Technical: HTTP's Content-Type header fields and CoAP Content-Formats can contain (media type) parameters (like COSE's cose-type), the definition of header parameter 3 seems to allow this only on the (unsigned) integer side (Content-Format), not for a tstr. While discriminator strings such as "Signature", "Signature1", and "CounterSignature" are cute, maybe a numeric label would be more appropriate for processing by a constrained implementation. (I know that these are just processed, not exchanged. Still.) If we don't mind spurious stuff in signer input, we should include "protected" even for COSE_Sign1 (as an empty bstr), simplifying implementation. Why are kids always bstr? It seems natural to allow tstrs here. key_ops could more naturally be a bit field (CDDL .bits). And start from 0. I don't understand the effect of Appendix A. Does this relieve the statements earlier of the form "The 'alg' parameter MUST be present."? (I'll add my ceterum censeo about private-use spaces and the X-Dash effect.) # Editorial/technical While the changes discussed here do not change the technical substance of the protocol, they may facilitate implementation. The definition of the "protected" header map fields should use more of what CDDL can do to define them, see #154. Please use consistent spacing, "label: value" (preferred) or consistently "label : value"; that makes searching so much simpler. Hmm, Sign1, Encrypt1, and Mac0. Sign1 contains 1 signature. Encrypt1 contains 0 recipient structures. Mac0 contains 0 recipient structures. Find the odd one out :-) I think it would be less confusing to have Sign1, Encrypt0, and Mac0. The counter signature parameter (parameter 7) contains one or more counter signatures, not just one. One of the nice things about JOSE is that the various labels have a defined name, which is then re-used as a variable or field name in an implementation. We are not really providing the same level of service. (Also cf. the previous paragraph -- this is talking about a parameter called "counter signature", but that doesn't stand out in that sentence, so I also referenced the parameter number 7.) A related problem are sentences such as o The 'kty' field MUST be present and it MUST be 'Symmetric'. Of course, we mean it must be 4 (and not the string 'Symmetric' in bstr or tstr form), but it would not help to state this numerically. 10.2.1 o The key and nonce pair MUST be unique for every message encrypted. (for a single key, that is) 12.2 o At a minimum, the 'unprotected' field MUST contain the 'alg' parameter and SHOULD contain a parameter identifying the shared secret. Why is the first a MUST if we can have the second? (The 'unprotected' field could be attacker-controlled; information attached to the shared secret cannot be.) # Editorial 1.1 and the rest of the document don't agree whether it is "MAC messages" or "MACed messages". Since the messages do not only contain a MAC, the second phrasing is more accurate. 1.2 and 1.5 could be combined, as someone searching for terminology might find one of them and then not the other. 1.4 could possibly be read as completely ruling out non int/tstr map keys in any CBOR contained in COSE messages; maybe it could be more explicit that this constraint is on the message structures defined by this specification. 2., second item list Maybe introduce local terms "untagged message" and "tagged message" in item 1 and 2, resp. 3. "Two buckets..." Maybe add example "(i.e., the byte string h'a0')" to clarify what a CBOR-serialized empty map is. I think I understand what the sentence with "finesses" is trying to say, but it may be confusing. (Same with "vindicated" in 9.1 -- we probably can agree on the gist of this statement, but at least the dictionary sense "clear (someone) of blame or suspicion" is not appropriate here.) Some of the statements in 3 also are true for key structures, that is not always clear. "should perform the same checks that..." -> "should also check that the same label does not occur in both the protected and unprotected headers" 4. "cannot be converted" -- of course they can. They just lose something then. Can we be more explicit what is that what we lose? 4.2 "COSE Single signature messages" -- what is that? 4.3 "if the same relative numbering is kept" -- huh? (Of course, you wouldn't.) 5.4 (define AE algorithm) 6.3 How is that "encode it as a binary value" done? 6.3 Maybe we can use names like ToBeMaced at the place where the input is defined so the reference later is clearer. (Twice.) 10.2.1 "the portions encryption" -- Huh? There are (fortunately few) cases of text that is repeated without need. PartyVInfo could really just explained as analogous to PartyUInfo. 12.1.2 unpredictable for whom? 12.2 The "MUST deal" is still not that clear. 12.4 second para, second sentence. Hmm. COSE is designed to be usable in that environment, but that doesn't mean it never can be used in an "on-line" environment (we actually plan to do this in CoAP "object security"). 16.9 The cose-key media types are sometimes called cose-key+cbor and sometimes cose-key. If we don't have +cbor on application/cose itself, why should it be on the key types? # Editorial, covered in #158 1. I prefer the abbreviation "IoT" (IOT is interoperability testing to some of us) 4.4 s/consistent/well-defined/ 5.4 s/absent/empty/g # Other Where the evolution from RFC 2633 to RFC 5751 is mentioned, maybe there could be a brief mention that there was another stage (RFC 3851). From nobody Sun Jun 12 19:26:12 2016 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 7293F12D757 for ; Sun, 12 Jun 2016 19:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SUBJ_ALL_CAPS=1.506] autolearn=no 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 rkV3RqamMITE for ; Sun, 12 Jun 2016 19:26:08 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1270612D5B2 for ; Sun, 12 Jun 2016 19:26:08 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 1A0C02CA06; Sun, 12 Jun 2016 19:26:06 -0700 (PDT) From: "Jim Schaad" To: "'Carsten Bormann'" , "'Justin Richer'" References: <87B21730-AD6A-4D00-AEBB-72E78A55B6C8@mit.edu> <575842B6.5070401@tzi.org> <575DBF01.3050608@tzi.org> In-Reply-To: <575DBF01.3050608@tzi.org> Date: Sun, 12 Jun 2016 19:26:06 -0700 Message-ID: <08a001d1c51a$f0de7f30$d29b7d90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH1IsgQ1lNISR9mQJ01+1RyLGXdawHJHAbjAgH9plqfgUCzYA== Content-Language: en-us Archived-At: Cc: 'cose' Subject: Re: [COSE] WGLC 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: Mon, 13 Jun 2016 02:26:09 -0000 Text changes can be found at = https://github.com/cose-wg/cose-spec/pull/160 More comments inline Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Sunday, June 12, 2016 12:59 PM > To: Justin Richer > Cc: cose > Subject: Re: [COSE] WGLC >=20 > Carsten Bormann wrote: > > expect my full review >=20 > Below. > This was one of the better drafts I have reviewed in my IETF life. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > The COSE message syntax draft is mostly ready to implement. > Some further editorial work could improve the document. > (Pull request #158 contains some typos and other trivial editorial > improvements.) >=20 > # Process >=20 > 8.2 > Are we creating a dependency here on a document that might take = forever to > complete? > Maybe mark this section with a "Sollbruchstelle" (~ toilet paper = perforation), so > it can be detached into a separate document if that happens. While it might be that it takes forever to finish, this is not the = impression that I have of where the RG chairs want to be. At worst = this might stall the final publication of the RFC but I would be = surprised if it was by far. Also I would note that this is an = Informative reference this means that it is possible to publish with a = reference to the ID just like we are going to do with the CDDL document. >=20 > # Technical >=20 > 2. second item list, item 3/4. > The media type system REST adopted from MIME is represented by the = Content- > Type header field in HTTP and the Content-Format (!) Option in CoAP. = (The > latter also covers what is Content-Encoding in HTTP.) > Editorial: The text here is about media types, and only then about how = these are > represented in the REST protocols. > Technical: CoAP Content-Formats are represented by unsigned integers, = not > integers in general (fix header parameter 3, content type). I think you covered this in your pull request. If not, what are you = looking for. >=20 > Related in 3.1: > Technical: HTTP's Content-Type header fields and CoAP Content-Formats = can > contain (media type) parameters (like COSE's cose-type), the = definition of > header parameter 3 seems to allow this only on the > (unsigned) integer side (Content-Format), not for a tstr. Your right it makes sense to allow this. It is a loss of functionality = from the JOSE documents that I missed. >=20 > While discriminator strings such as "Signature", "Signature1", and > "CounterSignature" are cute, maybe a numeric label would be more = appropriate > for processing by a constrained implementation. > (I know that these are just processed, not exchanged. Still.) This was the hardest one for me to think about and respond to. I can = understand why you are saying this. I wish that could whole heartedly = agree but I can't. I can agree with shortening these strings, but going = to integers just seems to me to be asking for potential problems in the = future if we start having other structures created, or even the current = structures being re-purposed for a different specific purpose. I also = think that strings are easier for people to recognize problems in = general. Not sure yet what to do about this. >=20 > If we don't mind spurious stuff in signer input, we should include = "protected" > even for COSE_Sign1 (as an empty bstr), simplifying implementation. If we allow this, I would not want to allow it as an empty bstr but as = something that would be totally different. That being the case I don't = think that absent is any harder than nil would be. Making this an = absent field might make it slightly harder to implement, but given that = you need to deal with the fact that the sources of information is = different I don't think that there is a real problem here. >=20 > Why are kids always bstr? It seems natural to allow tstrs here. I don't see any real benefit to that. Allowing for two types now means = that you need to worry about what the type is if you are going to = display, you need to keep the type for doing comparisons and so forth. = This would seem to make things complicated. If one wishes to do a = textual display one can see if it follows a text constrained format and = then do the display if one wishes to. >=20 > key_ops could more naturally be a bit field (CDDL .bits). > And start from 0. That would be true for the set of key ops that we have defined. = However, it would mean that future applications would potentially have a = more difficult time creating a key op for their specific purpose. I = would worry that applications would only expect a small value for the = bit field and have problems with larger values. This is not a problem = with the current method. >=20 > I don't understand the effect of Appendix A. Does this relieve the = statements > earlier of the form "The 'alg' parameter MUST be present."? That would be for a specific application to state. But in the generic = case it does not. >=20 > (I'll add my ceterum censeo about private-use spaces and the X-Dash > effect.) >=20 > # Editorial/technical >=20 > While the changes discussed here do not change the technical substance = of the > protocol, they may facilitate implementation. >=20 > The definition of the "protected" header map fields should use more of = what > CDDL can do to define them, see #154. >=20 > Please use consistent spacing, "label: value" (preferred) or = consistently "label : > value"; that makes searching so much simpler. Done - although I disagree on the preferred version. >=20 > Hmm, Sign1, Encrypt1, and Mac0. Sign1 contains 1 signature. Encrypt1 = contains > 0 recipient structures. Mac0 contains 0 recipient structures. Find = the odd one > out :-) I think it would be less confusing to have Sign1, Encrypt0, = and Mac0. Yes you are right >=20 > The counter signature parameter (parameter 7) contains one or more = counter > signatures, not just one. >=20 > One of the nice things about JOSE is that the various labels have a = defined name, > which is then re-used as a variable or field name in an = implementation. We are > not really providing the same level of service. > (Also cf. the previous paragraph -- this is talking about a parameter = called > "counter signature", but that doesn't stand out in that sentence, so I = also > referenced the parameter number 7.) A related problem are sentences = such as > o The 'kty' field MUST be present and it MUST be = 'Symmetric'. > Of course, we mean it must be 4 (and not the string 'Symmetric' in = bstr or tstr > form), but it would not help to state this numerically. Not sure how to address this comment. I can be more proactive about = making sure that the single quotes are used everywhere that it is the = name of a parameter field rather than a concept and mark that in the = terminology section up top. Is that going to be enough or do you have a = more solid proposal? >=20 > 10.2.1 > o The key and nonce pair MUST be unique for every message = encrypted. > (for a single key, that is) I am not sure what you are asking for here. It would be equally true to = have the note "(for a single nonce, that is)". >=20 > 12.2 > o At a minimum, the 'unprotected' field MUST contain the = 'alg' > parameter and SHOULD contain a parameter identifying the = shared > secret. > Why is the first a MUST if we can have the second? > (The 'unprotected' field could be attacker-controlled; information = attached to > the shared secret cannot be.) The first falls out from the requirement that an 'alg' parameter always = be present in a message. One could also use this in the absence of a = 'kid' to filter out the set of keys to be used. The second would be insufficient if the same secret could be used for = multiple algorithms. I.e. it could be used for both a key wrap = algorithm in a recipient structure and as a CEK for an Encrypt0 message = with a different algorithm. In both cases you are going to end up in a situation of having a denial = of service attack if either value was changed by an attacker. =20 >=20 > # Editorial >=20 > 1.1 and the rest of the document don't agree whether it is "MAC = messages" or > "MACed messages". Since the messages do not only contain a MAC, the = second > phrasing is more accurate. That makes sense >=20 > 1.2 and 1.5 could be combined, as someone searching for terminology = might > find one of them and then not the other. >=20 > 1.4 could possibly be read as completely ruling out non int/tstr map = keys in any > CBOR contained in COSE messages; maybe it could be more explicit that = this > constraint is on the message structures defined by this specification. I think you are probably being overly paranoid, however I made some = changes for this >=20 > 2., second item list > Maybe introduce local terms "untagged message" and "tagged message" in = item > 1 and 2, resp. I have identified both of these terms in the 2nd bullet. This makes me = wonder if I should swap the order of bullets 1 and 2. >=20 > 3. "Two buckets..." > Maybe add example "(i.e., the byte string h'a0')" to clarify what a = CBOR- > serialized empty map is. That makes sense >=20 > I think I understand what the sentence with "finesses" is trying to = say, but it may > be confusing. (Same with "vindicated" in 9.1 -- we probably can agree = on the gist > of this statement, but at least the dictionary sense "clear (someone) = of blame or > suspicion" is not appropriate here.) The dictionary also has "to show that (someone or something that has = been criticized or doubted) is correct, true, or reasonable" for this as = well. But I can see the point. >=20 > Some of the statements in 3 also are true for key structures, that is = not always > clear. If this is true, then those statements should be echoed in section 7 as = well. Which statements do you think are missing there. >=20 > "should perform the same checks that..." -> "should also check that = the same > label does not occur in both the protected and unprotected headers" Yes, that works better >=20 > 4. > "cannot be converted" -- of course they can. They just lose something = then. > Can we be more explicit what is that what we lose? Done >=20 > 4.2 > "COSE Single signature messages" -- what is that? Done >=20 > 4.3 > "if the same relative numbering is kept" -- huh? > (Of course, you wouldn't.) On a strictly na=C3=AFve implementer basis, I am willing to bet that = this might be one of the most common bugs that is going to pop up when = testing. If you copy over the correct set of options in the sender and = then do the same in the validator 90+ percent of the time it is going to = be just fine and work just great. Only if the set of options actually = gets changed during the testing process is it going to be a problem. >=20 > 5.4 > (define AE algorithm) Done >=20 > 6.3 > How is that "encode it as a binary value" done? Missed that one when the other two were re-written >=20 > 6.3 > Maybe we can use names like ToBeMaced at the place where the input is > defined so the reference later is clearer. (Twice.) done >=20 > 10.2.1 > "the portions encryption" -- Huh? Cleaned up >=20 Section 11.2 > There are (fortunately few) cases of text that is repeated without = need. > PartyVInfo could really just explained as analogous to PartyUInfo. Given that I pulled out the PartyInfo structure, it makes sense to cut = this down even farther. >=20 > 12.1.2 > unpredictable for whom? I don't think it matters who it is unpredictable for, but I would = consider there to be a distinction between random and a "predictable" = but random method such as encrypting a counter which is incremented. >=20 > 12.2 > The "MUST deal" is still not that clear. The following text seems to be to be clear what this means. Can you = elaborate on what you think is not clear? >=20 > 12.4 second para, second sentence. > Hmm. COSE is designed to be usable in that environment, but that = doesn't mean > it never can be used in an "on-line" environment (we actually plan to = do this in > CoAP "object security"). I think of the way you are using it more as a store-and-forward without = necessarily having a separate store entity. After all, the protocol = that you are outlining would work just as well in a true = store-and-forward environment as well. However, I can also think of it = as being an 'on-line' protocol as well. These are the terms that I have = normally used for distinguishing between message based protocols and = something like TLS/DTLS which is more session based. Do you have a = suggestion for a better pair of contrasting terms for this? >=20 > 16.9 > The cose-key media types are sometimes called cose-key+cbor and = sometimes > cose-key. If we don't have +cbor on application/cose itself, why = should it be on > the key types? I had a reason for doing it this way, but I cannot seem to find a = historical note that I left myself about why I removed the +cbor for one = of them and not for the other. It might have some vague reasoning that = I was thinking of the possibility of a different encoding being used for = the key structures but not for the message structures but I can't think = of why that would have been. >=20 > # Editorial, covered in #158 >=20 > 1. > I prefer the abbreviation "IoT" > (IOT is interoperability testing to some of us) >=20 > 4.4 > s/consistent/well-defined/ >=20 > 5.4 > s/absent/empty/g >=20 > # Other >=20 > Where the evolution from RFC 2633 to RFC 5751 is mentioned, maybe = there > could be a brief mention that there was another stage (RFC 3851). >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Sun Jun 12 22:58:23 2016 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 1A26E12B03F for ; Sun, 12 Jun 2016 22:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics-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 T2WvhkRHGO9w for ; Sun, 12 Jun 2016 22:58:20 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 E3D3012B00E for ; Sun, 12 Jun 2016 22:58:19 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id f6so56910786lfg.0 for ; Sun, 12 Jun 2016 22:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=WOlp63MhFFcQQUc84rTevLlq1eOPEmOeS0QJ6yXSfmQ=; b=wYweBVtlpc4HSf5Y/13XztXBsfsC/GRpB1Cd4HDfIis1wKevx/iZjEpQlHAZ/8gcq4 ZsMkPa2tkIfEsKxRytV5rSnL1QugJiY66BDqMYJeRwVSUv5cNR8nWQZNBd4hPLlfyfCv KteELObNuHqXb0RtqFOyW5z7M5iZVjcOq2xAfmGd4/fm2bv4l3qhXp+WhKaXuDYhlgKf nQ4tvV/HM1iGx5E1I0KKcNz+bFIreETtTdpF7QJtqvzg2Ka1MoRaNyw1lw+8+LujUBvO GB7lEETfl2LEnxvqzpz7scQvuLFtY+X/92tdbdf+IiBlfTokSFzx0fBjM7C8hiw5y15z 9SxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=WOlp63MhFFcQQUc84rTevLlq1eOPEmOeS0QJ6yXSfmQ=; b=lHB074jnY5aWdWA6vQ2NQECfBI6DgYTL8UHO10GZnBDLKNBVu9CYS7NeL3Zt0JNAD4 GtJ6jYqmDD9fwaTkk60t4hxjFto2NMWqiTT02+ZfyvVDddVaXWnTDBgAg2M25veZvmwL Nw6ejtYY8AlsthgQ0VtdYfUalwxo2Sq2TyuEdyAD+Y4/hHPnEfkPvARyamHyjXDK9IGU G+F3TXTa836tlZkuCB5h55xGLUbw1TCozJPZ4Rwg2+9uJuCNh6vJiKZykH70aWK0FaKI XcuYBogBww98rT0cj5BLwWg2DoAI2dNDbzsN5O+zATM4a8dTwpwlIwqUkk0s0xjxJOFn kkdA== X-Gm-Message-State: ALyK8tKXV5mqh46wvhhfreLkg+kEZBKImfxqJ2RX7BPvkV16V15EnOcBRc/IwiLgODRmKzOa X-Received: by 10.46.1.83 with SMTP id 80mr3185130ljb.22.1465797497873; Sun, 12 Jun 2016 22:58:17 -0700 (PDT) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id 73sm600645ljf.8.2016.06.12.22.58.16 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Jun 2016 22:58:17 -0700 (PDT) To: cose@ietf.org References: <87B21730-AD6A-4D00-AEBB-72E78A55B6C8@mit.edu> From: Ludwig Seitz Message-ID: <575E4B73.9090809@sics.se> Date: Mon, 13 Jun 2016 07:58:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <87B21730-AD6A-4D00-AEBB-72E78A55B6C8@mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090609040106030809020703" Archived-At: Subject: Re: [COSE] WGLC 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: Mon, 13 Jun 2016 05:58:22 -0000 This is a cryptographically signed message in MIME format. --------------ms090609040106030809020703 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2016-06-08 17:50, Justin Richer wrote: > Hi everyone, > > Has anybody read the draft? Comments, thoughts, snide remarks? > Hello, I spotted two typos in one sentence of 8.2.1. "Signing and non-batch signature verification are deterministic=20 operations and do not nee random nuber of any kind." "need" and "number" /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=C3=A4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms090609040106030809020703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK /swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji /GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0 +jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84 MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6 V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA 0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf 1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/ tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH 2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9 VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp /2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjA2MTMwNTU4MTFaMC8GCSqGSIb3DQEJBDEiBCCBukyZaIqt w4KjuS8EfUGK7wfi5MaRu3decKjenLuiWzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQC45KG/5BsCmXYzOdUIQUGK 4staA/3bNEjoNFxmUnYOakBR6XzONfzn8BzSN+BiDO24jkDZ4NKYLtgFCVzfWcXwa/F6WBj7 KKoh70xX3Nz+Q9RMjiSSgbg/tHoByKoXawdd/V8wK/+lmugFJ4zOhNXyMgcsXNbdmKmLk1vW 7z17T9O1LIJ2+7AkEyJXRPHlOjKg7u7yMckr3gLi5WCne3YBDxL1hDYMFioS1mDUOLz7huop NBlpHZ6y+K5l19DXaUdd4bPy5ZQQtBug058853i7AtG/UMATiiroJOu9v94lDGQ8AksnnWao d6p7fymExBwGFaOkRzlU0QiKJSYyWGt4AAAAAAAA --------------ms090609040106030809020703-- From nobody Sun Jun 12 23:43:24 2016 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 45BF612B007 for ; Sun, 12 Jun 2016 23:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 BWkt9rzb2vq8 for ; Sun, 12 Jun 2016 23:43:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A8C128E19 for ; Sun, 12 Jun 2016 23:43:19 -0700 (PDT) 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=sMBOZ/Dc/zysBNFVADhdw1B/euQ1SYgmsfqOKEcHxjs=; b=fcS0Jf016wDNm7unH7Jrk4VkaLgMsU9CLAMccFyDz167RN2fJMPb+yg90jRTu+KvoGAzkBS/3AfRWFEJdYWUCXHP18AY3K47q83kzQNthP3ZwNyUTL1mUsEMcXkp5A2eqZKfU3eDVyRi/EmM2gO2QRxzDYZ+TjMqFOX+pNVjME8= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1647.namprd03.prod.outlook.com (10.162.130.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Mon, 13 Jun 2016 06:43:17 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0517.009; Mon, 13 Jun 2016 06:43:17 +0000 From: Mike Jones To: "cose@ietf.org" Thread-Topic: WGLC comments from Mike Jones on draft-ietf-cose-msg-12 Thread-Index: AdHFH6+ZAtL9wcDQSc+Jq7OqgS30Jg== Date: Mon, 13 Jun 2016 06:43:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.90.97] x-ms-office365-filtering-correlation-id: 236bb279-9660-4422-6253-08d393560096 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1647; 6:gm6yP+fZF7OWwOsYsG3qn6GpoZACVkHbYz3qr3RboP27kzth1hIwf2cce7ejEmqLRuPuyJm7HEbQ7ZMCanTuhvMuw8EE6rjLhQeI9bFfzz+QKtZRvcOShEE+c784INwCiHW6ELunlr4qXcGF1mdZO7u7ftmS5kmpsuOoQYo5R36UX84HBXMz/br4xNOaaOV/IYux//WA29dR69stZWVB1Gklxncci6AZMsaBQaeiuQc5/EtPoI1Kd9e59D53JoekOqXWpATnADSbwtejd56M75hIEahXNxnJOq9q43PV0fb78cIrumVQDsbYhhrNyakEohHxlMFyzOiRHyBpmG9nzg==; 5:WzYW8pekTBoBA1Etjg7I0a6STb4Q3OyvPEja7roWhSt/tgavOn//023C0cZjQmGnDPA7zv0RazmtRzKZb6JMWKelFNvmnGB9F1cvqJV2Vm/dNX8FCs1P3TJsFFiXP9l1oi8f9z1AM0oDwvXBlH7Nmw==; 24:8M55bxcCXk8V0h0Z0xlnSzsygnpaLN1QimzA9oPrpYUGj2HvB4AYFmrHCr1lvpI8PKQWycNy3SADBUGFWfGwkIaw1Tqu9Rkve/YkYzAQkiw=; 7:Cr8WTqKh4hRGcg0J3LC4zuh5G1ePfsWTxcWeastjoP7Ar9bFXr5zoIWN8ByjF0j+mhN/Bnnh2BkOhj8Q680EMbkKi145CJ8fKTKlkewOiyK0uXNlA20pBTH20q7dw21D4tFinpyi3c/7LIVt7T19tXETfcdTRxweGfR8G0Vy/M0IPSwDJdkULKDgtY7t2sqIJfLCrcz8/zK8FKuBDKxOqRUHiOUufPBrBSffpLdEk8eaj1lX4hWyWWvI5WO/m9pp x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(166708455590820)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1647; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1647; x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(450100001)(19625215002)(122556002)(5003600100002)(5004730100002)(5005710100001)(86612001)(10400500002)(10090500001)(3660700001)(3280700002)(11100500001)(10290500002)(189998001)(106356001)(8990500004)(50986999)(19300405004)(66066001)(101416001)(54356999)(5002640100001)(99286002)(86362001)(87936001)(74316001)(68736007)(81156014)(81166006)(8676002)(1730700003)(2906002)(586003)(76576001)(19617315012)(5630700001)(110136002)(2900100001)(97736004)(2501003)(9686002)(102836003)(8936002)(6116002)(790700001)(16236675004)(92566002)(2351001)(3846002)(107886002)(5008740100001)(5640700001)(229853001)(15975445007)(105586002)(33656002)(230783001)(77096005)(19580395003)(7906002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1647; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16450CF65DF059D8984DF39BF5530SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2016 06:43:17.3822 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1647 Archived-At: Subject: [COSE] WGLC comments from Mike Jones on draft-ietf-cose-msg-12 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: Mon, 13 Jun 2016 06:43:23 -0000 --_000_SN1PR0301MB16450CF65DF059D8984DF39BF5530SN1PR0301MB1645_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll say up front that this spec is much improved since the last time I did= a full read through. Good progress. Substantive comments meriting working group visibility are in this note. C= orrections to grammatical, punctuation, and consistency nits are contained = in the accompanying GitHub pull request, https://github.com/cose-wg/cose-sp= ec/pull/161, which (lightly) touches 160 lines. =3D=3D=3D=3D Document Title: Change "CBOR Encoded Message Syntax" to "CBOR Object Signing and Encryption= (COSE)" so that the title contains and explains the intended acronym for t= he work. 1.4. CBOR Related Terminology Please change "Applications can either fail processing or process messages = with incorrect labels, however they MUST NOT create messages with incorrect= labels" to "Applications MUST fail processing for messages with incorrect = labels and they MUST NOT create messages with incorrect labels". The curre= nt wording is a major security hole in a security specification. Please cl= ose the hole! Also, please consider moving this important semantic requirement to a secti= on other than the terminology section, in which it is likely to be overlook= ed. 2. Basic COSE Structure Readers could be misled by the very general wording of this section into th= inking that COSE_Key structures are COSE Messages, as defined in this secti= on. Saying explicitly that a COSE_Key is not a COSE Message would help eli= minate this potential source of confusion. One of the places that I was confused in this way was the text "The followi= ng CDDL fragment identifies all of the top level messages defined in this d= ocument". And yet even though COSE_Key is a top-level data structure, it w= asn't in the list. 3. Header Parameters In "Applications SHOULD perform the same checks that the labels appearing i= n the protected and unprotected headers are unique as well", change the "SH= OULD" to "MUST". This is the same security hole as in 1.4, which needs to = be closed. Then delete the then-superfluous sentence: "If the message is n= ot rejected as malformed, attributes MUST be obtained from the protected bu= cket before they are obtained from the unprotected bucket." The following sentence seems garbled or as if it's missing word(s) near "ge= neric": "It uses forward references to a group definition of headers for ge= neric and algorithms." Please revise. In the following text, I can't tell what "; Algorithm_Headers," is intended= to mean. Is it a comment on either the previous or subsequent line? If s= o, maybe move it onto the line. header_map =3D { Generic_Headers, ; Algorithm_Headers, * label =3D> values } 4.4. Signing and Verification Process In the following sentence, I can't work out what "the appropriate authoriza= tion is done" refers to: "In addition to performing the signature verificat= ion, one must also perform the appropriate checks to ensure that the key is= correctly paired with the signing identity and that the appropriate author= ization is done." Please clarify. 5.3. Encryption Algorithm for AEAD algorithms This instruction is ambiguous because it doesn't say how the key is represe= nted: "For recipients of the message, recursively perform the encryption al= gorithm for that recipient, using the encryption key as the plain text". I= suspect "encryption key" should be changed to "encryption key represented = as a COSE_Key structure". This same language also occurs in 5.4. 7.1. COSE Key Common Parameters Change either the order of the parameters in Table 3 or the order of their = descriptions afterwards so that they are presented in the same order in bot= h places. 11.2. Context Information Structure In the AlgorithmID description, it should probably say that the AlgorithmID= is represented in the same manner as the 'alg' header parameter. 12.2. Key Wrapping Similarly to the ambiguity in 5.3 and 5.4, the text "The plain text to be e= ncrypted is the key from next layer down" doesn't say how the key is repres= ented. In this case, I think it's a raw symmetric key that's encrypted, ri= ght? Please say what it is. A.2. Counter Signature Without Headers Should the "counter signature w/o headers | 9 | bstr" value in Table 27 be = added to the appropriate registry? If the answer is "no", please change "9= " to "TBD". Thanks, -- Mike --_000_SN1PR0301MB16450CF65DF059D8984DF39BF5530SN1PR0301MB1645_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll say up front that this spec is much impro= ved since the last time I did a full read through.  Good progress.

 

Substantive comments meriting working group visibili= ty are in this note.  Corrections to grammatical, punctuation, and con= sistency nits are contained in the accompanying GitHub pull request, https://github.co= m/cose-wg/cose-spec/pull/161, which (lightly) touches 160 lines.

 

=3D=3D=3D=3D

 

Document Title:

Change “CBOR Encoded Message Syntax” to = “CBOR Object Signing and Encryption (COSE)” so that the title c= ontains and explains the intended acronym for the work.

 

1.4.  CBOR Related Terminology

Please change “Applications can either fail pr= ocessing or process messages with incorrect labels, however they MUST NOT c= reate messages with incorrect labels” to “Applications MUST fai= l processing for messages with incorrect labels and they MUST NOT create messages with incorrect labels”.  The curr= ent wording is a major security hole in a security specification.  Ple= ase close the hole!

 

Also, please consider moving this important semantic= requirement to a section other than the terminology section, in which it i= s likely to be overlooked.

 

2.  Basic COSE Structure

Readers could be misled by the very general wording = of this section into thinking that COSE_Key structures are COSE Messages, a= s defined in this section.  Saying explicitly that a COSE_Key is not a= COSE Message would help eliminate this potential source of confusion.

 

One of the places that I was confused in this way wa= s the text “The following CDDL fragment identifies all of the top lev= el messages defined in this document”.  And yet even though COSE= _Key is a top-level data structure, it wasn’t in the list.

 

3.  Header Parameters

 

In “Applications SHOULD perform the same check= s that the labels appearing in the protected and unprotected headers are un= ique as well”, change the “SHOULD” to “MUST”.=   This is the same security hole as in 1.4, which needs to be closed.&= nbsp; Then delete the then-superfluous sentence: “If the message is not re= jected as malformed, attributes MUST be obtained from the protected bucket = before they are obtained from the unprotected bucket.”

 

The following sentence seems garbled or as if itR= 17;s missing word(s) near “generic”: “It uses forward ref= erences to a group definition of headers for generic and algorithms.”=   Please revise.

 

In the following text, I can’t tell what ̶= 0;; Algorithm_Headers,” is intended to mean.  Is it a comment on= either the previous or subsequent line?  If so, maybe move it onto th= e line.

 

header_map =3D {

    Generic_Headers,

    ; Algorithm_Headers,

    * label =3D> values=

}

 

4.4.  Signing and Verification Process

In the following sentence, I can’t work out wh= at “the appropriate authorization is done” refers to: “In= addition to performing the signature verification, one must also perform t= he appropriate checks to ensure that the key is correctly paired with the signing identity and that the appropriate authorization is= done.”  Please clarify.

 

5.3.  Encryption Algorithm for AEAD algorithms<= o:p>

This instruction is ambiguous because it doesn’= ;t say how the key is represented: “For recipients of the message, re= cursively perform the encryption algorithm for that recipient, using the en= cryption key as the plain text”.  I suspect “encryption key” should be changed to “encryption key represented as a COS= E_Key structure”.  This same language also occurs in 5.4.

 

7.1.  COSE Key Common Parameters

Change either the order of the parameters in Table 3= or the order of their descriptions afterwards so that they are presented i= n the same order in both places.

 

11.2.  Context Information Structure=

In the AlgorithmID description, it should probably s= ay that the AlgorithmID is represented in the same manner as the ‘alg= ’ header parameter.

 

12.2.  Key Wrapping

Similarly to the ambiguity in 5.3 and 5.4, the text = “The plain text to be encrypted is the key from next layer down”= ; doesn’t say how the key is represented.  In this case, I think= it’s a raw symmetric key that’s encrypted, right?  Please say what it is.

 

A.2.  Counter Signature Without Headers

Should the “counter signature w/o headers | 9 = | bstr” value in Table 27 be added to the appropriate registry? = If the answer is “no”, please change “9” to “= ;TBD”.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Thanks,

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

 

 

--_000_SN1PR0301MB16450CF65DF059D8984DF39BF5530SN1PR0301MB1645_-- From nobody Sun Jun 12 23:44:50 2016 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 DD94912B00E for ; Sun, 12 Jun 2016 23:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no 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 dc70wjRtdk2a for ; Sun, 12 Jun 2016 23:44:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0798.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:798]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FEBB128E19 for ; Sun, 12 Jun 2016 23:44:47 -0700 (PDT) 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=Csz0Skw9r9L2yzplamS3h2/LCo3Cw854o9HOFV72R8I=; b=DfncgiG7nlB4HGa4JZA6H0jfbAEV/6YHORtk1k+mx/UBT87hoetuOXjSUQaGX6fR+dZFvA3xm451x+o+LmOge2E6TZx4bu1gmsm/EqPrFQtjoye7wVf6/imYaQXsTwBhuZQsm3xHguvC/lFjxAWLL/1CDCKUU5Z/CaalEW8XR3w= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1647.namprd03.prod.outlook.com (10.162.130.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Mon, 13 Jun 2016 06:44:30 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0517.009; Mon, 13 Jun 2016 06:44:30 +0000 From: Mike Jones To: Ludwig Seitz , "cose@ietf.org" Thread-Topic: [COSE] WGLC Thread-Index: AQHRwZ1tTJuMbLLp50ykjSfzqNQ4Hp/m7eaAgAAM1FA= Date: Mon, 13 Jun 2016 06:44:30 +0000 Message-ID: References: <87B21730-AD6A-4D00-AEBB-72E78A55B6C8@mit.edu> <575E4B73.9090809@sics.se> In-Reply-To: <575E4B73.9090809@sics.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.90.97] x-ms-office365-filtering-correlation-id: d9ddfbb5-f156-4152-423e-08d393562c47 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1647; 6:VwUXNg6HBy5RVbtTHZR3lWzJhedn9GbjTkuhIlu904qEajl0nnQ5g6x6O9LZSDZcKoHGKcQqnEoaFrcuOKgKyxXEY97zKuGKM2S9NC4nbaN2+3m+8fWuyIDgJKZWroIlYwqjyNB4n9wrDHPbshBT+cTn8uigA5D8rijBczzw2GqYgSGwqQh/s0VvR0x+M4tP1H5tsJ1tpkDRztv3xV3mbcSMXP09clq1YfjLCsY3uNYdm43hUcZYDcriAlLvfVklzzw+HFjCQ5lvWVdxT6YAg085lHWp39pmzGcwZ8XdddV9MQcuURZ0hHXwkST2xvJ/1V2zklz/iKVG2ul302ciUw==; 5:Mgrt7FVyF5qvLgEJOvTFHp0t6LV88U6iPRiM/S9yqfUqbwsAKDxy81BvtMDXQ33vKcor2C84csvMlC/tiR5++ulIsa5wG74liAvQ8VzHG20kDKrglsZ+9AnvF6qGzRYexVfXrE6V6+gsN1NF3esW2A==; 24:lvdQQyn8yE8BQWiyTEAioSc5HiRpy/PEWRHtqZARFiXKYK2G3yijMQatvN4smyrz0ENf6Ave8ImpqGuc1CYBh8HtMcc9mIKN82+P1kgv/MI=; 7:gjK2CBZkK3I7pEg02UbHMUn3MR8DEYYHyiOm10gUgnSFmM6xwxhMGyvtD5thnnbfAL+Lvac96xyvE121kMQovriONm6OLCvVJtBDctH1ZoXZf3djLYjsHARMV96BNAEbzbBJF/4PpnN1NqLC8s5Kg5gm1VZ36P6yfeFH067OJY7d3Ypu5UGrw2Lhg0t2bT3jDF/wzqa/2XnM/jZZ/oy/CPBbim6s4vRQPPtv01knaEARkzIqrK7TdBLxNb7tuyyS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1647; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1647; x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(377424004)(53754006)(24454002)(189002)(13464003)(122556002)(5003600100002)(76176999)(5004730100002)(5005710100001)(86612001)(10400500002)(10090500001)(3660700001)(3280700002)(11100500001)(10290500002)(189998001)(106356001)(8990500004)(50986999)(66066001)(101416001)(54356999)(5002640100001)(99286002)(86362001)(87936001)(74316001)(68736007)(81156014)(81166006)(8676002)(2950100001)(5001770100001)(2906002)(586003)(76576001)(2900100001)(97736004)(2501003)(9686002)(102836003)(8936002)(6116002)(92566002)(106116001)(3846002)(107886002)(5008740100001)(15975445007)(105586002)(33656002)(19580405001)(77096005)(19580395003)(18886065003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1647; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2016 06:44:30.7418 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1647 Archived-At: Subject: Re: [COSE] WGLC 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: Mon, 13 Jun 2016 06:44:49 -0000 SSBzcG90dGVkIHRob3NlIHRvby4gIFRoZXkncmUgYWN0dWFsbHkgYWxyZWFkeSBmaXhlZCBpbiB0 aGUgR2l0SHViIHZlcnNpb24uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBD T1NFIFttYWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTHVkd2lnIFNl aXR6DQpTZW50OiBTdW5kYXksIEp1bmUgMTIsIDIwMTYgMTA6NTggUE0NClRvOiBjb3NlQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW0NPU0VdIFdHTEMNCg0KT24gMjAxNi0wNi0wOCAxNzo1MCwgSnVz dGluIFJpY2hlciB3cm90ZToNCj4gSGkgZXZlcnlvbmUsDQo+DQo+IEhhcyBhbnlib2R5IHJlYWQg dGhlIGRyYWZ0PyBDb21tZW50cywgdGhvdWdodHMsIHNuaWRlIHJlbWFya3M/DQo+DQoNCkhlbGxv LA0KDQpJIHNwb3R0ZWQgdHdvIHR5cG9zIGluIG9uZSBzZW50ZW5jZSBvZiA4LjIuMS4NCg0KIlNp Z25pbmcgYW5kIG5vbi1iYXRjaCBzaWduYXR1cmUgdmVyaWZpY2F0aW9uIGFyZSBkZXRlcm1pbmlz dGljIG9wZXJhdGlvbnMgYW5kIGRvIG5vdCBuZWUgcmFuZG9tIG51YmVyIG9mIGFueSBraW5kLiIN Cg0KIm5lZWQiIGFuZCAibnVtYmVyIg0KDQoNCi9MdWR3aWcNCg0KDQotLQ0KTHVkd2lnIFNlaXR6 LCBQaEQNClNJQ1MgU3dlZGlzaCBJQ1QgQUINCklkZW9uIFNjaWVuY2UgUGFyaw0KQnVpbGRpbmcg QmV0YSAyDQpTY2hlZWxldsOkZ2VuIDE3DQpTRS0yMjMgNzAgTHVuZA0KDQpQaG9uZSArNDYoMCk3 MC0zNDkgOTIgNTENCmh0dHA6Ly93d3cuc2ljcy5zZQ0KDQo= From nobody Mon Jun 13 00:28:31 2016 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 7BF9112B03C for ; Mon, 13 Jun 2016 00:28:25 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kTC63you2j8r for ; Mon, 13 Jun 2016 00:28:24 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BDE12B009 for ; Mon, 13 Jun 2016 00:28:23 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-4b-575e6071d609 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 62.C9.12926.1706E575; Mon, 13 Jun 2016 09:27:45 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.158]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0294.000; Mon, 13 Jun 2016 09:27:45 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad Thread-Topic: [COSE] WGLC, One more week Thread-Index: AQHRvftKXiBym6eodUO2KqwCqX86l5/i6wEAgABUKICAA88PgA== Date: Mon, 13 Jun 2016 07:27:44 +0000 Message-ID: References: <073401d1c36e$54e41e30$feac5a90$@augustcellars.com> In-Reply-To: <073401d1c36e$54e41e30$feac5a90$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <158391C7291B1941B8C29A2BB327C46C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM2K7iu7UhLhwgx+HTCymbZ3KarF6+nc2 iw3XXrI6MHtsnDOdzWPJkp9MHk1njjIHMEdx2aSk5mSWpRbp2yVwZbz/c5C9YJ9YxfePl1gb GL+IdjFyckgImEhs3vmSGcIWk7hwbz1bFyMXh5DAEUaJ3n0zWCCcJYwSP1qes4FUsQm4SDxo eMQEYosIqEtsXX0TzGYWcJPYdOotexcjB4cwUPzKxVSIEg2JpjOLWSBsJ4njvz6ALWMRUJXo ffOMEcTmFbCQmLRiM9Su+YwS7TOOgiU4BRwklh29C9bACHTd91NroHaJS9x6Mp8J4moBiSV7 zkN9ICrx8vE/VhBbVEBP4su9eYwQcSWJRbc/M4HcxiygKbF+lz7EGGuJ11tuskDYihJTuh+y Q9wjKHFy5hOWCYwSs5Bsm4XQPQtJ9ywk3bOQdC9gZF3FKFqcWpyUm25krJdalJlcXJyfp5eX WrKJERiZB7f8Vt3BePmN4yFGAQ5GJR7ehNux4UKsiWXFlbmHGCU4mJVEeG/5xoUL8aYkVlal FuXHF5XmpBYfYpTmYFES5/V/qRguJJCeWJKanZpakFoEk2Xi4JRqYLS03L4j8wzPH488w9an nnfN8y7lBcc+jZ+jJ5jEW3qUjTOz3+Yad1uzMWPxNMZc2Ygvj7QiXhY9viun2TtRc9kT3faE fYpT7v2alnf1ao1qGnvAoUAx/ylCJzqTt8x9ti8569rq39/qV4tvLGRf5+Yky7lO+fJF8zs5 mhbbmbcUrjE0sRfYoMRSnJFoqMVcVJwIAOfKpaHIAgAA Archived-At: Cc: 'Justin Richer' , "cose@ietf.org" Subject: Re: [COSE] WGLC, One more week 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: Mon, 13 Jun 2016 07:28:25 -0000 DQoNCk9uIDIwMTYtMDYtMTEgMDE6MTcsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCj4+DQo+PlNlY3Rpb24gNS4yDQo+PiJUaGUgQ09TRV9FbmNyeXB0MSBl bmNyeXB0ZWQgc3RydWN0dXJlIGRvZXMgbm90IGhhdmUgdGhlIGFiaWxpdHkgdG8NCj4+c3BlY2lm eQ0KPj5yZWNpcGllbnRzIG9mIHRoZSBtZXNzYWdlLiBUaGUgc3RydWN0dXJlIGFzc3VtZXMgdGhh dCB0aGUgcmVjaXBpZW50IG9mDQo+PnRoZSBvYmplY3QNCj4+d2lsbCBhbHJlYWR5IGtub3cgdGhl IGlkZW50aXR5IG9mIHRoZSBrZXkgdG8gYmUgdXNlZCBpbiBvcmRlciB0byBkZWNyeXB0DQo+PnRo ZQ0KPj5tZXNzYWdlLiBJZiBhIGtleSBuZWVkcyB0byBiZSBpZGVudGlmaWVkIHRvIHRoZSByZWNp cGllbnQsIHRoZSBlbnZlbG9wZWQNCj4+c3RydWN0dXJlDQo+Pm91Z2h0IHRvIGJlIHVzZWQu4oCd DQo+Pk9uZSB0eXBlIG9mIGNvbXBhY3QgZW5jcnlwdGlvbiBmb3JtYXRzIHdlIGhhdmUgbG9va2Vk IGF0IGhhcyBiZWVuLA0KPj5lc3NlbnRpYWxseTogW2tleSBpZGVudGlmaWVyLCBjaXBoZXIgdGV4 dF0gKGRpc3JlZ2FyZGluZyBJViBldGMuKS4gV2UNCj4+d291bGQgbGlrZSB0bw0KPj51c2UgQ09T RV9FbmNyeXB0MSB3aGljaCBlc3NlbnRpYWxseSBpczogW2FsZ29yaXRobSwgY2lwaGVyIHRleHRd DQo+PihkaXNyZWdhcmRpbmcgSVYNCj4+ZXRjLikuIE1ha2luZyBhbGdvcml0aG0gb3B0aW9uYWwg aXMgY292ZXJlZCBpbiBBcHBlbmRpeCBBLiBCdXQgSSByZWFkDQo+PnRoZSB0ZXh0DQo+PmFib3Zl IGFzIHVzaW5nIHRoaXMgZm9ybWF0IHdpdGggYSBraWQgaGVhZGVyIGlzIG5vdCBwb3NzaWJsZSwg aXMgdGhhdA0KPj50aGUgaW50ZW50aW9uPw0KPj5JIGNhbiBtYXliZSB1bmRlcnN0YW5kIHRoaXMg ZnJvbSBhIGxldmVsL2xheWVyIHN0cnVjdHVyZSBwb2ludCBvZiwgYnV0DQo+Pm5vdCByZWFsbHkN Cj4+ZnJvbSBhIHNlY3VyaXR5IHBvaW50IG9mIHZpZXcuDQo+DQo+VGhlIGNob2ljZSBvZiB0aGUg d29yZCAnb3VnaHQnIHdhcyB2ZXJ5IGRlbGliZXJhdGUuICBUaGUgaW50ZW50aW9uIGlzIHRvDQo+ c2F5IHRoYXQgdGhpcyBpcyB3aGF0IGl0IGlzIGJlbGlldmVkIHNob3VsZCBiZSBkb25lLCBidXQg aXQgaXMgbm90IGJ5IGFueQ0KPm1lYW5zIGEgc3RhdGVtZW50IG9mIHJlcXVpcmVtZW50LiAgWW91 IGNhbiB2aW9sYXRlIHRoaXMgd2l0aG91dCBiZWluZyBpbg0KPnZpb2xhdGlvbiBvZiB0aGUgcnVs ZXMsIGJ1dCB5b3Ugc2hvdWxkIHJlYWxseSB0aGluayBhYm91dCB3aHkgeW91IGFyZQ0KPmRvaW5n IGl0Lg0KDQpTb21lIG1vcmUgdGhvdWdodHMgb24gdGhpcy4NCg0KSSB1bmRlcnN0YW5kIHRoaXMg aXMgbm90IG5vcm1hdGl2ZS4NCg0KSXQgc291bmRzIGxpa2UgeW91IHNheSBpdCBpcyBub3QgcmVj b21tZW5kZWQgKFNIT1VMRCBOT1QpIGJ1dCBpcyBhbGxvd2VkDQooTUFZKSBnaXZlbiBjZXJ0YWlu IGltcG9ydGFudCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhcmUgbWFkZS4NCg0KLSBXaHkgbm90 IGZvcm11bGF0ZSBpdCBsaWtlIHRoYXQ/DQoNCi0gSSBkaWRu4oCZdCBmaW5kIGFueSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBzcGVjaWZpY2FsbHkgb24gdGhpcywgYnV0IG1heQ0KaGF2ZSBtaXNz ZWQgdGhlbS4gSWYgdGhleSBhcmUgbm90IGFscmVhZHkgaW4sIEkgdGhpbmsgc29tZSBjb25zaWRl cmF0aW9ucw0Kc2hvdWxkIGJlIGluY2x1ZGVkLiBDb21wYXJpbmcgd2l0aCBEVExTLCB0aGVyZSBp cyBlc3NlbnRpYWxseSBhIFNlbmRlciBJRA0KKGRpc3JlZ2FyZGluZyBJViBldGMuKSwgbm8gYWxn b3JpdGhtIGFuZCBubyBlbnZlbG9wZWQgc3RydWN0dXJlLiBJIGFzc3VtZQ0KdGhhdCBEVExTIGZ1 bGZpbHMgdGhvc2Ugc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIHNvIG1heWJlIHRoYXQgY2FuIHNl cnZlDQphcyBhIGdvb2QgZXhhbXBsZT8NCg0KU2luY2UgdGhpcyBtYXkgYmUgYSBzcGVjaWFsIGNh c2Ugb2Ygbm8gYWxnb3JpdGhtLCBzb21lIHRleHQgYWJvdXQgdGhlIGNhc2UNCmluIHF1ZXN0aW9u IGNvdWxkIGJlIGluY2x1ZGVkIGluIEFwcGVuZGl4IEEuDQoNCg0KR8O2cmFuDQoNCg== From nobody Mon Jun 13 15:31:37 2016 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 B807512DAB2 for ; Mon, 13 Jun 2016 15:31:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 EYGSZNEtDw1Q for ; Mon, 13 Jun 2016 15:31:20 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B4A12D9E9 for ; Mon, 13 Jun 2016 15:31:20 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 7EAE438EF0; Mon, 13 Jun 2016 15:31:19 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , =?iso-8859-1?Q?'G=F6ran_Selander'?= References: , <073401d1c36e$54e41e30$feac5a90$@augustcellars.com> In-Reply-To: Date: Mon, 13 Jun 2016 15:31:19 -0700 Message-ID: <097c01d1c5c3$4eb0cfc0$ec126f40$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_097D_01D1C588.A25700D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIpPzywWYU+9lbmJceVi3vGPxt34wJTUoRJAtlqApcB4tDXyp8AiwHA Content-Language: en-us Archived-At: Cc: 'Justin Richer' , cose@ietf.org Subject: Re: [COSE] WGLC, One more week 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: Mon, 13 Jun 2016 22:31:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_097D_01D1C588.A25700D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable While this would make the items match, I don=92t really think that the = title you are suggesting is more descriptive than the one I suggested. I am = to the point where I am ready to argue with the RFC Editor about the rule = of expanding acronyms in the title if the title itself is descriptive of = what the document is doing. =20 =20 Jim =20 =20 From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, June 10, 2016 4:47 PM To: Jim Schaad ; 'G=F6ran Selander' Cc: 'Justin Richer' ; cose@ietf.org Subject: Re: [COSE] WGLC, One more week =20 Why not just the title CBOR Object Signing and Encryption (COSE)? Then = the title and acronym would match. =20 =96 Mike =20 =20 From: Jim Schaad =20 Sent: Friday, June 10, 2016 6:18 PM To: 'G=F6ran Selander' =20 Cc: 'Justin Richer' ; cose@ietf.org =20 Subject: Re: [COSE] WGLC, One more week =20 Just this last week I ended up in a situation where somebody used an = acronym that I did not understand that highlights one of your points below. Somebody was asking me questions about CEMS and I did not understand = until some ways into the conversation that they were referring to "CBOR = Encoded Message Syntax".=20 I am reluctant to use CEMS as a short hand for this, in part because it = is just too close to CMS and I personally don't want to get confused = between the two different specifications when people start asking me questions = out of the blue. I have been using the term COSE to refer to this work as a single entity without trying to differentiate between the different structures as JOSE = did with the JWS, JWE, JWK, JWE. It is not clear if they use the term JOSE = for the overall set of specs within their community or not. I know that I frequently will use it myself when I talk to people. =20 I would like to promulgate the use of COSE as the short hand term for = this specification and the follow on work done just like CMS is used for that = set of specifications. For that reason, I would like to keep the current = set of references to COSE as an item rather than using it as a modifier. I do however think that I need to change the title of the document to make = this work. How do people feel about a new title of "COSE: An encryption and signing solution for CBOR". Other notes inline Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of G=F6ran = Selander > Sent: Friday, June 10, 2016 9:16 AM > To: Jim Schaad = > > Cc: Justin Richer >; cose@ietf.org =20 > Subject: Re: [COSE] WGLC, One more week >=20 > Only a few comments, and with one exception only comments on = readability. >=20 > For someone that hasn't a clue what this is about, the first encounter with the > term "COSE" (apart from "COSE Working Group" in the header") is just before > 1.1: It is now defined in the introduction. >=20 > o "COSE is not a direct copy of the JOSE specification. " >=20 > - It would be nice if the term "COSE" was first defined in terms of = what it is, > rather than what it is not. >=20 > - Should the term "COSE" be used independently at all, or instead = always > together with some noun as in "COSE Message", "cose type", etc.? >=20 > In section 2; title is "Basic COSE Structure" but as is explained it = is actually about > the COSE Message structure. >=20 > Similarly in section 3 :"The structure of COSE has been designed . . = ." >=20 > Section 2 uses the term "COSE object=94, is that different from "COSE Message=94? > (When referencing the constructs of this draft we consistently used = the term > "COSE object", since there is often other data included in the actual message > being sent.) I switch to using COSE object everywhere. =20 >=20 >=20 > Section 4.3 >=20 > "The primary reason for supporting this can be seen by looking at the = CoAP > message structure [RFC7252] where the facility exists for options to = be carried > before the payload. An example of data that can be placed in this = location would > be CoAP options for transaction ids and nonces to check for replay protection. If > the data is in the options section, then it is available for routers = to help in > performing the replay detection and prevention. However, it may also = be > desired to protect these values so that if they are be modified in = transit it can be > detected.=94 >=20 > To my knowledge, there are no proposed CoAP options for transaction id = or > nonces, at least not such that are proposed to be integrity protected, = but there > may be other CoAP options that needs to be integrity protected only. I have done a re-write on this >=20 >=20 >=20 > Section 5.2 >=20 > "The COSE_Encrypt1 encrypted structure does not have the ability to specify > recipients of the message. The structure assumes that the recipient of = the object > will already know the identity of the key to be used in order to = decrypt the > message. If a key needs to be identified to the recipient, the = enveloped structure > ought to be used.=94 >=20 > One type of compact encryption formats we have looked at has been, > essentially: [key identifier, cipher text] (disregarding IV etc.). We would like to > use COSE_Encrypt1 which essentially is: [algorithm, cipher text] (disregarding IV > etc.). Making algorithm optional is covered in Appendix A. But I read = the text > above as using this format with a kid header is not possible, is that = the intention? > I can maybe understand this from a level/layer structure point of, but = not really > from a security point of view. The choice of the word 'ought' was very deliberate. The intention is to = say that this is what it is believed should be done, but it is not by any = means a statement of requirement. You can violate this without being in = violation of the rules, but you should really think about why you are doing it. >=20 >=20 > Section 12.4.1, new bullet is fine, forgot to acknowledge that. >=20 >=20 > Appendix B in particular, but also other parts speak of =93levels=94 = and =93layers=94, > which seems like synonyms, or is there a difference? No they are the same thing. I have harmonized to layers. Jim >=20 >=20 > G=F6ran >=20 >=20 >=20 >=20 >=20 > On 2016-06-04 02:51, "COSE on behalf of Justin Richer" > > = wrote: >=20 > >Hi everyone, > > > >Just a gentle reminder that the WGLC on the COSE Messages draft = closes > >a week from today, on June 10 2016. Due to timezones, schedules, and > >the black art of SMTP delivery, we can't guarantee any particular = time > >during the day that the call will close. Therefore, if you've got > >something to say about the draft, please do so earlier in the week > >rather than later. No time like the present! > > > >The latest draft (12) is here: > > > >https://tools.ietf.org/html/draft-ietf-cose-msg-12 > > > >The issue tracker is here (but we'd prefer comments to the list in = this > >period): > > > >https://github.com/cose-wg/cose-issues/issues > > > >Please read and review, and we're even looking for "yup, it looks = good > >to me" from people if that's your take on things. > > > >Thanks everyone, > > > > -- Justin, your COSE chair > > > >_______________________________________________ > >COSE mailing list > >COSE@ietf.org =20 > >https://www.ietf.org/mailman/listinfo/cose >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org =20 > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list COSE@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose ------=_NextPart_000_097D_01D1C588.A25700D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

While this = would make the items match, I don’t really think that the title = you are suggesting is more descriptive than the one I suggested.=A0 I am = to the point where I am ready to argue with the RFC Editor about the = rule of expanding acronyms in the title if the title itself is = descriptive of what the document is doing.=A0

 

Jim

 

 

From:<= /b> = COSE [mailto:cose-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Friday, June 10, 2016 4:47 PM
To: Jim = Schaad <ietf@augustcellars.com>; 'G=F6ran Selander' = <goran.selander@ericsson.com>
Cc: 'Justin Richer' = <jricher@mit.edu>; cose@ietf.org
Subject: Re: [COSE] = WGLC, One more week

 

Why not just the title CBOR Object Signing and = Encryption (COSE)?  Then the title and acronym would = match.

 

– Mike

 

 

From: Jim Schaad
Sent: = Friday, June 10, 2016 6:18 PM
To: 'G=F6ran = Selander'
Cc: 'Justin = Richer'; cose@ietf.org
Subject: Re: = [COSE] WGLC, One more week

 

Just this last week I = ended up in a situation where somebody used an acronym that I did not = understand that highlights one of your points below.  Somebody was = asking me questions about CEMS and I did not understand until some ways = into the conversation that they were referring to "CBOR Encoded = Message Syntax".

I am reluctant to use CEMS as a short hand = for this, in part because it is just too close to CMS and I personally = don't want to get confused between the two different specifications when = people start asking me questions out of the blue.

I have been = using the term COSE to refer to this work as a single entity without = trying to differentiate between the different structures as JOSE did = with the JWS, JWE, JWK, JWE.  It is not clear if they use the term = JOSE for the overall set of specs within their community or not.  I = know that I frequently will use it myself when I talk to people.  =

I would like to promulgate the use of COSE as the short hand = term for this specification and the follow on work done just like CMS is = used for that set of specifications.  For that reason, I would like = to keep the current set of references to COSE as an item rather than = using it as a modifier.  I do however think that I need to change = the title of the document to make this work.  How do people feel = about a new title of "COSE: An encryption and signing solution for = CBOR".

Other notes inline

Jim


> = -----Original Message-----
> From: COSE [mailto:cose-bounces@ietf.org] = On Behalf Of G=F6ran Selander
> Sent: Friday, June 10, 2016 9:16 = AM
> To: Jim Schaad <ietf@augustcellars.com>
= > Cc: Justin Richer <jricher@mit.edu>; cose@ietf.org
> Subject: Re: = [COSE] WGLC, One more week
>
> Only a few comments, and = with one exception only comments on readability.
>
> For = someone that hasn't a clue what this is about, the first encounter with = the
> term "COSE" (apart from "COSE Working = Group" in the header") is just before
> 1.1:

It = is now defined in the introduction.

>
> o "COSE is = not a direct copy of the JOSE specification. "
>
> - = It would be nice if the term "COSE" was first defined in terms = of what it is,
> rather than what it is not.
>
> - = Should the term "COSE" be used independently at all, or = instead always
> together with some noun as in "COSE = Message", "cose type", etc.?
>
> In section = 2; title is "Basic COSE Structure" but as is explained it is = actually about
> the COSE Message structure.
>
> = Similarly in section 3 :"The structure of COSE has been designed . = . ."
>
> Section 2 uses the term "COSE = object”, is that different from "COSE Message”?
> = (When referencing the constructs of this draft we consistently used the = term
> "COSE object", since there is often other data = included in the actual message
> being sent.)

I switch to = using COSE object everywhere. 

>
>
> = Section 4.3
>
> "The primary reason for supporting = this can be seen by looking at the CoAP
> message structure = [RFC7252] where the facility exists for options to be carried
> = before the payload. An example of data that can be placed in this = location would
> be CoAP options for transaction ids and nonces to = check for replay protection. If
> the data is in the options = section, then it is available for routers to help in
> performing = the replay detection and prevention. However, it may also be
> = desired to protect these values so that if they are be modified in = transit it can be
> detected.”
>
> To my = knowledge, there are no proposed CoAP options for transaction id = or
> nonces, at least not such that are proposed to be integrity = protected, but there
> may be other CoAP options that needs to be = integrity protected only.

I have done a re-write on = this

>
>
>
> Section 5.2
>
> = "The COSE_Encrypt1 encrypted structure does not have the ability to = specify
> recipients of the message. The structure assumes that = the recipient of the object
> will already know the identity of = the key to be used in order to decrypt the
> message. If a key = needs to be identified to the recipient, the enveloped structure
> = ought to be used.”
>
> One type of compact encryption = formats we have looked at has been,
> essentially: [key = identifier, cipher text] (disregarding IV etc.). We would like = to
> use COSE_Encrypt1 which essentially is: [algorithm, cipher = text] (disregarding IV
> etc.). Making algorithm optional is = covered in Appendix A. But I read the text
> above as using this = format with a kid header is not possible, is that the intention?
> = I can maybe understand this from a level/layer structure point of, but = not really
> from a security point of view.

The choice of = the word 'ought' was very deliberate.  The intention is to say that = this is what it is believed should be done, but it is not by any means a = statement of requirement.  You can violate this without being in = violation of the rules, but you should really think about why you are = doing it.

>
>
> Section 12.4.1, new bullet is = fine, forgot to acknowledge that.
>
>
> Appendix B = in particular, but also other parts speak of “levels” and = “layers”,
> which seems like synonyms, or is there a = difference?

No they are the same thing.  I have harmonized = to layers.

Jim

>
>
> G=F6ran
> =
>
>
>
>
> On 2016-06-04 02:51, = "COSE on behalf of Justin Richer"
> <cose-bounces@ietf.org on behalf of jricher@mit.edu> = wrote:
>
> >Hi everyone,
> >
> >Just a = gentle reminder that the WGLC on the COSE Messages draft closes
> = >a week from today, on June 10 2016. Due to timezones, schedules, = and
> >the black art of SMTP delivery, we can't guarantee any = particular time
> >during the day that the call will close. = Therefore, if you've got
> >something to say about the draft, = please do so earlier in the week
> >rather than later. No time = like the present!
> >
> >The latest draft (12) is = here:
> >
> >https://tools= .ietf.org/html/draft-ietf-cose-msg-12
> >
> >The = issue tracker is here (but we'd prefer comments to the list in = this
> >period):
> >
> >https://github.com= /cose-wg/cose-issues/issues
> >
> >Please read and = review, and we're even looking for "yup, it looks good
> = >to me" from people if that's your take on things.
> = >
> >Thanks everyone,
> >
> >  -- = Justin, your COSE chair
> >
> = >_______________________________________________
> >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

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

<= /html> ------=_NextPart_000_097D_01D1C588.A25700D0-- From nobody Mon Jun 13 15:34:40 2016 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 3EB9612D9F2 for ; Mon, 13 Jun 2016 15:34:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 9mri89nVK6M3 for ; Mon, 13 Jun 2016 15:34:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7958112DABE for ; Mon, 13 Jun 2016 15:34:33 -0700 (PDT) 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=unecSTjmu/WKZInW5aEk97APBVk0u2cUMONyVG280yU=; b=PFm5PRJnB6KM7M1Gy2RfVUPHyTOouXUZsCPLvJ3C4wWySGYjh4tIvZx0ZteqztrerBm+YjRTBeYxaEZaJLnQunM3afDEI9uJIHxnnzm10AgZYGzED0JIKq3ohk0aXGgtCunfsWrLsAjZBgT17XMsTLUKw0eHZwQNSrSFeb50wWI= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1648.namprd03.prod.outlook.com (10.162.130.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Mon, 13 Jun 2016 22:34:12 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0517.009; Mon, 13 Jun 2016 22:34:12 +0000 From: Mike Jones To: Jim Schaad , =?iso-8859-1?Q?=27G=F6ran_Selander=27?= Thread-Topic: [COSE] WGLC, One more week Thread-Index: AQHRvftKB9od3a5J0UK317au9KDmm5/i6tCAgAB14ICAAAgp/oAEocyAgAAAXTA= Date: Mon, 13 Jun 2016 22:34:12 +0000 Message-ID: References: , <073401d1c36e$54e41e30$feac5a90$@augustcellars.com> <097c01d1c5c3$4eb0cfc0$ec126f40$@augustcellars.com> In-Reply-To: <097c01d1c5c3$4eb0cfc0$ec126f40$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:9::650] x-ms-office365-filtering-correlation-id: bc9ebc16-e12b-45a1-9caa-08d393dad7e5 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1648; 6:5aF57m/SGCMpV6+Mqh7SpvZTqPe8viaRL9IVDZgLDn8Pi7JRm1Z+CUgs7Br8SHhNblrapB7HIONJOVrKUoSpPFDPFCKq+2IO+POYfz5p/jv1xSjZ7WnceTokpdPuZ2SwVIRuSRBFrrNIyPhWP/KIKoe46g0XbxsYg3ibtlSSWJugGE8/90JMEy1cGvcfmhFfucKdcv9oxPN98985y+ZQ4IcZmeow091/sopAuVd7+f4nNE4kyNIHD89/WdF/zBrk74Chv+6+x4XL4PD0GOykGobi8JaLQyzH6Gh6ei/Mpfre9IgnFN4fEj7vF+wd2Tjp; 5:yeGgvy4sAPy/403y4feWkxDdfMklAH/+KjNwBSP+04dH98rHoJZTK2XM8bRAXhz9bP1CW9lhjsoKz3bFfvgQ26SLHn2fg0jWWbNyATZTrVKDzry8fJaVextaymK5gWAGzDqIqBxVdr0syx+RSKD7Eg==; 24:lR64dCcspq+uniomR7l1AuuysSdp0LaVGFW9ok6u6VhkGPcNsrSObCkjnRjicqCgyQsx6SaQp5yCf0sAYWDApbxzuzHx9cExc++pIUFXUYE=; 7:mMIb1nbxfOe+sgKPn9ZR4uCsunROyRRic3NqmUGGQ02PffnppW1XbxGMuYFT0ejNZ0iAOwdw3704orGrmJFXXcAAUHsEeQTAF+6VZRQi0jhh9sduCeLFhS8OieTq8/e6smaQyGHURC6U1SrRx1GjxmXODMHRqdXVoszwLzDotbKlAzY9DZJQMk2CQh0HHOvYOxGetZlZkO35agiM8lKeBnJkXCSStS/Zw5h1I2UFaw4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1648; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1648; x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(377424004)(53754006)(24454002)(13464003)(52024003)(189002)(4326007)(19580395003)(99286002)(10400500002)(10090500001)(790700001)(19300405004)(586003)(86612001)(2906002)(5005710100001)(19580405001)(3280700002)(122556002)(93886004)(92566002)(8936002)(101416001)(76176999)(3660700001)(6116002)(10290500002)(68736007)(8990500004)(102836003)(8676002)(7906002)(5008740100001)(5002640100001)(19609705001)(9686002)(2900100001)(2950100001)(74316001)(189998001)(105586002)(19617315012)(77096005)(15975445007)(5001770100001)(97736004)(5004730100002)(3900700001)(19625215002)(54356999)(87936001)(50986999)(81156014)(106116001)(106356001)(33656002)(86362001)(81166006)(76576001)(11100500001)(551934003)(5003600100002)(16236675004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1648; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1645CAE011AAA75C6CBB9093F5530SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2016 22:34:12.2581 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1648 Archived-At: Cc: 'Justin Richer' , "cose@ietf.org" Subject: Re: [COSE] WGLC, One more week 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: Mon, 13 Jun 2016 22:34:38 -0000 --_000_SN1PR0301MB1645CAE011AAA75C6CBB9093F5530SN1PR0301MB1645_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'd be OK with the title "COSE: An encryption and signing solution for CBOR= " if in the abstract and/or introduction you somewhere say that "COSE is an= acronym for CBOR Object Signing and Encryption" so readers who weren't fam= iliar with the working group know where the name came from. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, June 13, 2016 3:31 PM To: Mike Jones ; 'G=F6ran Selander' Cc: 'Justin Richer' ; cose@ietf.org Subject: RE: [COSE] WGLC, One more week While this would make the items match, I don't really think that the title = you are suggesting is more descriptive than the one I suggested. I am to t= he point where I am ready to argue with the RFC Editor about the rule of ex= panding acronyms in the title if the title itself is descriptive of what th= e document is doing. Jim From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, June 10, 2016 4:47 PM To: Jim Schaad >; 'G= =F6ran Selander' > Cc: 'Justin Richer' >; cose@ietf.or= g Subject: Re: [COSE] WGLC, One more week Why not just the title CBOR Object Signing and Encryption (COSE)? Then the= title and acronym would match. - Mike From: Jim Schaad Sent: Friday, June 10, 2016 6:18 PM To: 'G=F6ran Selander' Cc: 'Justin Richer'; cose@ietf.org Subject: Re: [COSE] WGLC, One more week Just this last week I ended up in a situation where somebody used an acrony= m that I did not understand that highlights one of your points below. Some= body was asking me questions about CEMS and I did not understand until some= ways into the conversation that they were referring to "CBOR Encoded Messa= ge Syntax". I am reluctant to use CEMS as a short hand for this, in part because it is = just too close to CMS and I personally don't want to get confused between t= he two different specifications when people start asking me questions out o= f the blue. I have been using the term COSE to refer to this work as a single entity wi= thout trying to differentiate between the different structures as JOSE did = with the JWS, JWE, JWK, JWE. It is not clear if they use the term JOSE for= the overall set of specs within their community or not. I know that I fre= quently will use it myself when I talk to people. I would like to promulgate the use of COSE as the short hand term for this = specification and the follow on work done just like CMS is used for that se= t of specifications. For that reason, I would like to keep the current set= of references to COSE as an item rather than using it as a modifier. I do= however think that I need to change the title of the document to make this= work. How do people feel about a new title of "COSE: An encryption and si= gning solution for CBOR". Other notes inline Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of G=F6ran Selander > Sent: Friday, June 10, 2016 9:16 AM > To: Jim Schaad > > Cc: Justin Richer >; cose@ietf.or= g > Subject: Re: [COSE] WGLC, One more week > > Only a few comments, and with one exception only comments on readability. > > For someone that hasn't a clue what this is about, the first encounter wi= th the > term "COSE" (apart from "COSE Working Group" in the header") is just befo= re > 1.1: It is now defined in the introduction. > > o "COSE is not a direct copy of the JOSE specification. " > > - It would be nice if the term "COSE" was first defined in terms of what = it is, > rather than what it is not. > > - Should the term "COSE" be used independently at all, or instead always > together with some noun as in "COSE Message", "cose type", etc.? > > In section 2; title is "Basic COSE Structure" but as is explained it is a= ctually about > the COSE Message structure. > > Similarly in section 3 :"The structure of COSE has been designed . . ." > > Section 2 uses the term "COSE object", is that different from "COSE Messa= ge"? > (When referencing the constructs of this draft we consistently used the t= erm > "COSE object", since there is often other data included in the actual mes= sage > being sent.) I switch to using COSE object everywhere. > > > Section 4.3 > > "The primary reason for supporting this can be seen by looking at the CoA= P > message structure [RFC7252] where the facility exists for options to be c= arried > before the payload. An example of data that can be placed in this locatio= n would > be CoAP options for transaction ids and nonces to check for replay protec= tion. If > the data is in the options section, then it is available for routers to h= elp in > performing the replay detection and prevention. However, it may also be > desired to protect these values so that if they are be modified in transi= t it can be > detected." > > To my knowledge, there are no proposed CoAP options for transaction id or > nonces, at least not such that are proposed to be integrity protected, bu= t there > may be other CoAP options that needs to be integrity protected only. I have done a re-write on this > > > > Section 5.2 > > "The COSE_Encrypt1 encrypted structure does not have the ability to speci= fy > recipients of the message. The structure assumes that the recipient of th= e object > will already know the identity of the key to be used in order to decrypt = the > message. If a key needs to be identified to the recipient, the enveloped = structure > ought to be used." > > One type of compact encryption formats we have looked at has been, > essentially: [key identifier, cipher text] (disregarding IV etc.). We wou= ld like to > use COSE_Encrypt1 which essentially is: [algorithm, cipher text] (disrega= rding IV > etc.). Making algorithm optional is covered in Appendix A. But I read the= text > above as using this format with a kid header is not possible, is that the= intention? > I can maybe understand this from a level/layer structure point of, but no= t really > from a security point of view. The choice of the word 'ought' was very deliberate. The intention is to sa= y that this is what it is believed should be done, but it is not by any mea= ns a statement of requirement. You can violate this without being in viola= tion of the rules, but you should really think about why you are doing it. > > > Section 12.4.1, new bullet is fine, forgot to acknowledge that. > > > Appendix B in particular, but also other parts speak of "levels" and "lay= ers", > which seems like synonyms, or is there a difference? No they are the same thing. I have harmonized to layers. Jim > > > G=F6ran > > > > > > On 2016-06-04 02:51, "COSE on behalf of Justin Richer" > > wrote: > > >Hi everyone, > > > >Just a gentle reminder that the WGLC on the COSE Messages draft closes > >a week from today, on June 10 2016. Due to timezones, schedules, and > >the black art of SMTP delivery, we can't guarantee any particular time > >during the day that the call will close. Therefore, if you've got > >something to say about the draft, please do so earlier in the week > >rather than later. No time like the present! > > > >The latest draft (12) is here: > > > >https://tools.ietf.org/html/draft-ietf-cose-msg-12 > > > >The issue tracker is here (but we'd prefer comments to the list in this > >period): > > > >https://github.com/cose-wg/cose-issues/issues > > > >Please read and review, and we're even looking for "yup, it looks good > >to me" from people if that's your take on things. > > > >Thanks everyone, > > > > -- Justin, your COSE chair > > > >_______________________________________________ > >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 _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose --_000_SN1PR0301MB1645CAE011AAA75C6CBB9093F5530SN1PR0301MB1645_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I’d be OK with the title "COSE: An encryption and signi= ng solution for CBOR" if in the abstract and/or = introduction you somewhere say that “COSE is an acronym for CBOR Object Signing and Encryption” so readers who weren’t= familiar with the working group know where the name came from.<= /span>

 

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

 

From: Jim Schaad [mailto:ietf@august= cellars.com]
Sent: Monday, June 13, 2016 3:31 PM
To: Mike Jones <Michael.Jones@microsoft.com>; 'G=F6ran Selande= r' <goran.selander@ericsson.com>
Cc: 'Justin Richer' <jricher@mit.edu>; cose@ietf.org
Subject: RE: [COSE] WGLC, One more week

 

While this would make the items match, I don’= t really think that the title you are suggesting is more descriptive than t= he one I suggested.  I am to the point where I am ready to argue with the RFC Editor about the rule of expanding acronyms in the t= itle if the title itself is descriptive of what the document is doing. = ;

 

Jim

 

 

From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, June 10, 2016 4:47 PM
To: Jim Schaad <ietf@au= gustcellars.com>; 'G=F6ran Selander' <goran.selander@ericsson.com>
Cc: 'Justin Richer' <jricher@m= it.edu>; cose@ietf.org
Subject: Re: [COSE] WGLC, One more week

 

Why not just the title CBOR Object Signing and Encr= yption (COSE)?  Then the title and acronym would match.

 

– Mike

 

 

From: Jim Schaad
Sent: Friday, June 10, 2016 6:18 PM
To: 'G=F6ran Selander= '
Cc: 'Justin Richer'; cose@ietf.org
Subject: Re: [COSE] WGLC, One more week

 

Just this last week= I ended up in a situation where somebody used an acronym that I did not un= derstand that highlights one of your points below.  Somebody was askin= g me questions about CEMS and I did not understand until some ways into the conversation that they were referring to "CB= OR Encoded Message Syntax".

I am reluctant to use CEMS as a short hand for this, in part because it is = just too close to CMS and I personally don't want to get confused between t= he two different specifications when people start asking me questions out o= f the blue.

I have been using the term COSE to refer to this work as a single entity wi= thout trying to differentiate between the different structures as JOSE did = with the JWS, JWE, JWK, JWE.  It is not clear if they use the term JOS= E for the overall set of specs within their community or not.  I know that I frequently will use it myself = when I talk to people. 

I would like to promulgate the use of COSE as the short hand term for this = specification and the follow on work done just like CMS is used for that se= t of specifications.  For that reason, I would like to keep the curren= t set of references to COSE as an item rather than using it as a modifier.  I do however think that I need t= o change the title of the document to make this work.  How do people f= eel about a new title of "COSE: An encryption and signing solution for= CBOR".

Other notes inline

Jim


> -----Original Message-----
> From: COSE [mailto:cose-bounc= es@ietf.org] On Behalf Of G=F6ran Selander
> Sent: Friday, June 10, 2016 9:16 AM
> To: Jim Schaad <ietf@augu= stcellars.com>
> Cc: Justin Richer <jricher@mit.e= du>; cose@ietf.org
> Subject: Re: [COSE] WGLC, One more week
>
> Only a few comments, and with one exception only comments on readabili= ty.
>
> For someone that hasn't a clue what this is about, the first encounter= with the
> term "COSE" (apart from "COSE Working Group" in th= e header") is just before
> 1.1:

It is now defined in the introduction.

>
> o "COSE is not a direct copy of the JOSE specification. " >
> - It would be nice if the term "COSE" was first defined in t= erms of what it is,
> rather than what it is not.
>
> - Should the term "COSE" be used independently at all, or in= stead always
> together with some noun as in "COSE Message", "cose typ= e", etc.?
>
> In section 2; title is "Basic COSE Structure" but as is expl= ained it is actually about
> the COSE Message structure.
>
> Similarly in section 3 :"The structure of COSE has been designed = . . ."
>
> Section 2 uses the term "COSE object”, is that different fr= om "COSE Message”?
> (When referencing the constructs of this draft we consistently used th= e term
> "COSE object", since there is often other data included in t= he actual message
> being sent.)

I switch to using COSE object everywhere. 

>
>
> Section 4.3
>
> "The primary reason for supporting this can be seen by looking at= the CoAP
> message structure [RFC7252] where the facility exists for options to b= e carried
> before the payload. An example of data that can be placed in this loca= tion would
> be CoAP options for transaction ids and nonces to check for replay pro= tection. If
> the data is in the options section, then it is available for routers t= o help in
> performing the replay detection and prevention. However, it may also b= e
> desired to protect these values so that if they are be modified in tra= nsit it can be
> detected.”
>
> To my knowledge, there are no proposed CoAP options for transaction id= or
> nonces, at least not such that are proposed to be integrity protected,= but there
> may be other CoAP options that needs to be integrity protected only.
I have done a re-write on this

>
>
>
> Section 5.2
>
> "The COSE_Encrypt1 encrypted structure does not have the ability = to specify
> recipients of the message. The structure assumes that the recipient of= the object
> will already know the identity of the key to be used in order to decry= pt the
> message. If a key needs to be identified to the recipient, the envelop= ed structure
> ought to be used.”
>
> One type of compact encryption formats we have looked at has been,
> essentially: [key identifier, cipher text] (disregarding IV etc.). We = would like to
> use COSE_Encrypt1 which essentially is: [algorithm, cipher text] (disr= egarding IV
> etc.). Making algorithm optional is covered in Appendix A. But I read = the text
> above as using this format with a kid header is not possible, is that = the intention?
> I can maybe understand this from a level/layer structure point of, but= not really
> from a security point of view.

The choice of the word 'ought' was very deliberate.  The intention is = to say that this is what it is believed should be done, but it is not by an= y means a statement of requirement.  You can violate this without bein= g in violation of the rules, but you should really think about why you are doing it.

>
>
> Section 12.4.1, new bullet is fine, forgot to acknowledge that.
>
>
> Appendix B in particular, but also other parts speak of “levels&= #8221; and “layers”,
> which seems like synonyms, or is there a difference?

No they are the same thing.  I have harmonized to layers.

Jim

>
>
> G=F6ran
>
>
>
>
>
> On 2016-06-04 02:51, "COSE on behalf of Justin Richer"
> <cose-bounces@ietf.org on behalf of jricher@mit.edu> wrot= e:
>
> >Hi everyone,
> >
> >Just a gentle reminder that the WGLC on the COSE Messages draft cl= oses
> >a week from today, on June 10 2016. Due to timezones, schedules, a= nd
> >the black art of SMTP delivery, we can't guarantee any particular = time
> >during the day that the call will close. Therefore, if you've got<= br> > >something to say about the draft, please do so earlier in the week=
> >rather than later. No time like the present!
> >
> >The latest draft (12) is here:
> >
> >htt= ps://tools.ietf.org/html/draft-ietf-cose-msg-12
> >
> >The issue tracker is here (but we'd prefer comments to the list in= this
> >period):
> >
> >https://= github.com/cose-wg/cose-issues/issues
> >
> >Please read and review, and we're even looking for "yup, it l= ooks good
> >to me" from people if that's your take on things.
> >
> >Thanks everyone,
> >
> >  -- Justin, your COSE chair
> >
> >_______________________________________________
> >COSE mailing list
> >COSE@ietf.org
> >https://www= .ietf.org/mailman/listinfo/cose
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.iet= f.org/mailman/listinfo/cose

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

--_000_SN1PR0301MB1645CAE011AAA75C6CBB9093F5530SN1PR0301MB1645_-- From nobody Mon Jun 13 17:04:04 2016 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 C042212D0FA for ; Mon, 13 Jun 2016 17:04:02 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ouxG8Mff8cwZ for ; Mon, 13 Jun 2016 17:04:00 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD2D12D74B for ; Mon, 13 Jun 2016 17:03:32 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 7DE372CA2D; Mon, 13 Jun 2016 17:03:31 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: In-Reply-To: Date: Mon, 13 Jun 2016 17:03:30 -0700 Message-ID: <099a01d1c5d0$2fce3e50$8f6abaf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_099B_01D1C595.83744850" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJZyheFG/A3N+1qs0UScrPT0oDgtp7X8nvQ Content-Language: en-us Archived-At: Subject: Re: [COSE] WGLC comments from Mike Jones on draft-ietf-cose-msg-12 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: Tue, 14 Jun 2016 00:04:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_099B_01D1C595.83744850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit See https://github.com/cose-wg/cose-spec/pull/162 From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Sunday, June 12, 2016 11:43 PM To: cose@ietf.org Subject: [COSE] WGLC comments from Mike Jones on draft-ietf-cose-msg-12 I'll say up front that this spec is much improved since the last time I did a full read through. Good progress. Substantive comments meriting working group visibility are in this note. Corrections to grammatical, punctuation, and consistency nits are contained in the accompanying GitHub pull request, https://github.com/cose-wg/cose-spec/pull/161, which (lightly) touches 160 lines. ==== Document Title: Change "CBOR Encoded Message Syntax" to "CBOR Object Signing and Encryption (COSE)" so that the title contains and explains the intended acronym for the work. [JLS] See previous mail 1.4. CBOR Related Terminology Please change "Applications can either fail processing or process messages with incorrect labels, however they MUST NOT create messages with incorrect labels" to "Applications MUST fail processing for messages with incorrect labels and they MUST NOT create messages with incorrect labels". The current wording is a major security hole in a security specification. Please close the hole! [JLS] What is the security hole that you see here. I don't see what it would be myself. Also, please consider moving this important semantic requirement to a section other than the terminology section, in which it is likely to be overlooked. 2. Basic COSE Structure Readers could be misled by the very general wording of this section into thinking that COSE_Key structures are COSE Messages, as defined in this section. Saying explicitly that a COSE_Key is not a COSE Message would help eliminate this potential source of confusion. One of the places that I was confused in this way was the text "The following CDDL fragment identifies all of the top level messages defined in this document". And yet even though COSE_Key is a top-level data structure, it wasn't in the list. [JLS] Deleted keys from the table. 3. Header Parameters In "Applications SHOULD perform the same checks that the labels appearing in the protected and unprotected headers are unique as well", change the "SHOULD" to "MUST". This is the same security hole as in 1.4, which needs to be closed. Then delete the then-superfluous sentence: "If the message is not rejected as malformed, attributes MUST be obtained from the protected bucket before they are obtained from the unprotected bucket." [JLS] This is not the same security hole as in section 1.4. They are talking about totally different subjects. There is no true security hole in this text given that a correct method of dealing with the problem is given should duplicates not be detected. I do not think that these need to be changed. The following sentence seems garbled or as if it's missing word(s) near "generic": "It uses forward references to a group definition of headers for generic and algorithms." Please revise. In the following text, I can't tell what "; Algorithm_Headers," is intended to mean. Is it a comment on either the previous or subsequent line? If so, maybe move it onto the line. header_map = { Generic_Headers, ; Algorithm_Headers, * label => values } [JLS] Originally I intended to create CDDL for the algorithm specific headers and I never did. All things considered I think it can just vanish. 4.4. Signing and Verification Process In the following sentence, I can't work out what "the appropriate authorization is done" refers to: "In addition to performing the signature verification, one must also perform the appropriate checks to ensure that the key is correctly paired with the signing identity and that the appropriate authorization is done." Please clarify. [JLS] Changed 5.3. Encryption Algorithm for AEAD algorithms This instruction is ambiguous because it doesn't say how the key is represented: "For recipients of the message, recursively perform the encryption algorithm for that recipient, using the encryption key as the plain text". I suspect "encryption key" should be changed to "encryption key represented as a COSE_Key structure". This same language also occurs in 5.4. [JLS] I have made a change - I don't know if it will resolve this for you or not. 7.1. COSE Key Common Parameters Change either the order of the parameters in Table 3 or the order of their descriptions afterwards so that they are presented in the same order in both places. [JLS] Done 11.2. Context Information Structure In the AlgorithmID description, it should probably say that the AlgorithmID is represented in the same manner as the 'alg' header parameter. [JLS] Done 12.2. Key Wrapping Similarly to the ambiguity in 5.3 and 5.4, the text "The plain text to be encrypted is the key from next layer down" doesn't say how the key is represented. In this case, I think it's a raw symmetric key that's encrypted, right? Please say what it is. [JLS] That would be based solely on what the next layer down wanted, I don't believe it is appropriate to make that statement at this point. A.2. Counter Signature Without Headers Should the "counter signature w/o headers | 9 | bstr" value in Table 27 be added to the appropriate registry? If the answer is "no", please change "9" to "TBD". [JLS] Done Thanks, -- Mike ------=_NextPart_000_099B_01D1C595.83744850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See   https://github.com= /cose-wg/cose-spec/pull/162

 

 

From: COSE = [mailto:cose-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Sunday, June 12, 2016 11:43 PM
To: = cose@ietf.org
Subject: [COSE] WGLC comments from Mike Jones on = draft-ietf-cose-msg-12

 

I’ll = say up front that this spec is much improved since the last time I did a = full read through.  Good progress.

 

Substantive = comments meriting working group visibility are in this note.  = Corrections to grammatical, punctuation, and consistency nits are = contained in the accompanying GitHub pull request, https://github.com= /cose-wg/cose-spec/pull/161, which (lightly) touches 160 = lines.

 

=3D=3D=3D=3D

 

Document = Title:

Change “CBOR Encoded = Message Syntax” to “CBOR Object Signing and Encryption = (COSE)” so that the title contains and explains the intended = acronym for the work.

 

[JLS] See previous mail

 

1.4.  = CBOR Related Terminology

Please = change “Applications can either fail processing or process = messages with incorrect labels, however they MUST NOT create messages = with incorrect labels” to “Applications MUST fail processing = for messages with incorrect labels and they MUST NOT create messages = with incorrect labels”.  The current wording is a major = security hole in a security specification.  Please close the = hole!

 

[JLS] What is the = security hole that you see here.  I don’t see what it would = be myself.

 

Also, please = consider moving this important semantic requirement to a section other = than the terminology section, in which it is likely to be = overlooked.

 

2.  Basic COSE Structure

Readers could be misled by the very general wording of = this section into thinking that COSE_Key structures are COSE Messages, = as defined in this section.  Saying explicitly that a COSE_Key is = not a COSE Message would help eliminate this potential source of = confusion.

 

One of the places that I was confused in this way was = the text “The following CDDL fragment identifies all of the top = level messages defined in this document”.  And yet even = though COSE_Key is a top-level data structure, it wasn’t in the = list.

 

[JLS] Deleted keys from = the table.

 

3.  = Header Parameters

 

In = “Applications SHOULD perform the same checks that the labels = appearing in the protected and unprotected headers are unique as = well”, change the “SHOULD” to = “MUST”.  This is the same security hole as in 1.4, = which needs to be closed.  Then delete the then-superfluous = sentence: “If the message is not rejected as malformed, attributes = MUST be obtained from the protected bucket before they are obtained from = the unprotected bucket.”

 

[JLS] This is not the same security hole as in = section 1.4.  They are talking about totally different = subjects.  There is no true security hole in this text given that a = correct method of dealing with the problem is given should duplicates = not be detected.  I do not think that these need to be = changed.

 

The = following sentence seems garbled or as if it’s missing word(s) = near “generic”: “It uses forward references to a group = definition of headers for generic and algorithms.”  Please = revise.

 

In the following text, I can’t tell what = “; Algorithm_Headers,” is intended to mean.  Is it a = comment on either the previous or subsequent line?  If so, maybe = move it onto the line.

 

header_map = =3D {

    = Generic_Headers,

    ; = Algorithm_Headers,

    = * label =3D> values

}

 

[JLS] Originally I intended to create CDDL for = the algorithm specific headers and I never did.  All things = considered I think it can just vanish.

 

4.4.  = Signing and Verification Process

In = the following sentence, I can’t work out what “the = appropriate authorization is done” refers to: “In addition = to performing the signature verification, one must also perform the = appropriate checks to ensure that the key is correctly paired with the = signing identity and that the appropriate authorization is = done.”  Please clarify.

 

[JLS]  Changed

 

5.3.  = Encryption Algorithm for AEAD algorithms

This instruction is ambiguous because it doesn’t = say how the key is represented: “For recipients of the message, = recursively perform the encryption algorithm for that recipient, using = the encryption key as the plain text”.  I suspect = “encryption key” should be changed to “encryption key = represented as a COSE_Key structure”.  This same language = also occurs in 5.4.

 

[JLS] I have made a change – I don’t = know if it will resolve this for you or not.

 

7.1.  = COSE Key Common Parameters

Change = either the order of the parameters in Table 3 or the order of their = descriptions afterwards so that they are presented in the same order in = both places.

 

[JLS] = Done

 

11.2.  Context Information = Structure

In the AlgorithmID = description, it should probably say that the AlgorithmID is represented = in the same manner as the ‘alg’ header = parameter.

 

[JLS] = Done

 

12.2.  Key Wrapping

Similarly to the ambiguity in 5.3 and 5.4, the text = “The plain text to be encrypted is the key from next layer = down” doesn’t say how the key is represented.  In this = case, I think it’s a raw symmetric key that’s encrypted, = right?  Please say what it is.

 

[JLS] That would be based solely on what the = next layer down wanted, I don’t believe it is appropriate to make = that statement at this point.

 

A.2.  = Counter Signature Without Headers

Should the “counter signature w/o headers | 9 | = bstr” value in Table 27 be added to the appropriate = registry?  If the answer is “no”, please change = “9” to “TBD”.

 

[JLS] = Done

 

 

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;         = Thanks,

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;         -- = Mike

 

 

------=_NextPart_000_099B_01D1C595.83744850-- From nobody Tue Jun 14 12:20:25 2016 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 35D8412D922 for ; Tue, 14 Jun 2016 12:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 vdxGyvdcSn0Y for ; Tue, 14 Jun 2016 12:20:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27B712D925 for ; Tue, 14 Jun 2016 12:20:17 -0700 (PDT) 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=QvOsF/EpcTHhgwKYtX2t53J+o+BXm5WAyPyYGDZTwLQ=; b=NkU88A8Bt7AzGTmKgOgjn1Tkqf57V5ry0FH2STsBJiWhDqiNCo0OAeVnmIjceXTcV1wcD1I5fvfdXeO23csKrT2+++7da919FF+whqfXjm6fsRTj/XuL7RKjI+ykRY1HZXMC1PXUQ04TCtGfXvYvIUWjTBk+0oT3rr40Yxb09kc= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1647.namprd03.prod.outlook.com (10.162.130.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Tue, 14 Jun 2016 19:20:15 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0517.011; Tue, 14 Jun 2016 19:20:16 +0000 From: Mike Jones To: "cose@ietf.org" Thread-Topic: WGLC comments from Mike Jones on draft-ietf-cose-msg-12 Thread-Index: AdHFH6+ZAtL9wcDQSc+Jq7OqgS30JgBUfjog Date: Tue, 14 Jun 2016 19:20:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:2::328] x-ms-office365-filtering-correlation-id: 150d08d7-6cba-4f66-0b6f-08d39488ea87 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1647; 6:U6MEerlug1wd6FNxuKHsPT5gLjh/wSGgRSxnzoq6otW0XcbwcvQ0VTWkOOdhFgIi7kmPxCnU9igYXBnsmW23IUb18N6PKKdhD6jx/lvNocmVbIkL9DiFhjTC98suO8suGYAdmo/tqNUDmZZfMssDHdZJUkcDJsfjUmjbX3z/cfU1BxrCwnYalHeaFD+n3j/A+rmB6pHVPkP0YQbh+4lzn7WjGyCE1Wcc1DZuZ2ajuyhgw0FTnLFLL89MHU0uLz/edk6t87NB4aRvY868kAVCLkrHaFSi4XtdGVltux7Q480Ynmt7euwCB1if/onlziGvmoRz29BaTF1W414dyB0YPw==; 5:c3QMnzpdVbbFFdx/0yeuN8bvu76sWNoY7E2/5T73SGGElSOHUY4H9DhY+GWfij4qwepU0DgU/59dmhu+QijxZ2cuWeb2QIp/zArsoFmVHaXhbYxCp7RP6dEu/wv/zrhRDXuiCE90aFzxylcGR50+Eg==; 24:HZdnjRS0VFxwtqBohdWlxYzYxawxqE+qih/RHZA+L/nqY8xCG1q8NGLnHqKtxNYhSGUN5+L7NTpIyjWEdEnLlSo/WDtWXswVlXu//yLHsXY=; 7:m8KE2VhdEOE4E4aDJfxYCdpJtmr985SpkOZixx9GBCEom0voml9bH0mFuuZN5eajEVJq4ahWECFXTyiYx17uYq/g7IOKGSiHXafdk9mI+lwEEtk7frtvl9ZItoTeeGPrlbflhQlcubvIZgdA6t5VRN1ZQoUPb0ydGhZ4tnwdtJoVBB4pEe8MtZozhQd+I/onlXL5i7yGF4RYIQfKGv4hPRfEvn3dG/wOAuKoexi1EaTHLWLS8x6iNVTcSM54aBDx x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(166708455590820)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1647; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1647; x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(199003)(50986999)(76176999)(8676002)(1730700003)(101416001)(81166006)(81156014)(10090500001)(5003600100002)(54356999)(5002640100001)(2351001)(105586002)(19617315012)(8936002)(106356001)(15975445007)(9686002)(74316001)(5630700001)(5640700001)(10290500002)(586003)(8990500004)(68736007)(97736004)(3900700001)(33656002)(450100001)(77096005)(102836003)(230783001)(6116002)(790700001)(189998001)(19625215002)(86612001)(19300405004)(3660700001)(7906002)(19580405001)(5008740100001)(19580395003)(3280700002)(16236675004)(87936001)(122556002)(5004730100002)(86362001)(2900100001)(76576001)(99286002)(5005710100001)(10400500002)(2501003)(92566002)(2906002)(2950100001)(110136002)(107886002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1647; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16451B251A1994D541E0ABFFF5540SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 19:20:15.8991 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1647 Archived-At: Subject: Re: [COSE] WGLC comments from Mike Jones on draft-ietf-cose-msg-12 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: Tue, 14 Jun 2016 19:20:24 -0000 --_000_SN1PR0301MB16451B251A1994D541E0ABFFF5540SN1PR0301MB1645_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim - I have updated https://github.com/cose-wg/cose-spec/pull/161 to remov= e the two proposed changes that you disagreed with. Unless you weren't don= e reading the pull request changes, this should now be ready to merge. -- Mike From: Mike Jones Sent: Sunday, June 12, 2016 11:43 PM To: cose@ietf.org Subject: WGLC comments from Mike Jones on draft-ietf-cose-msg-12 I'll say up front that this spec is much improved since the last time I did= a full read through. Good progress. Substantive comments meriting working group visibility are in this note. C= orrections to grammatical, punctuation, and consistency nits are contained = in the accompanying GitHub pull request, https://github.com/cose-wg/cose-sp= ec/pull/161, which (lightly) touches 160 lines. =3D=3D=3D=3D Document Title: Change "CBOR Encoded Message Syntax" to "CBOR Object Signing and Encryption= (COSE)" so that the title contains and explains the intended acronym for t= he work. 1.4. CBOR Related Terminology Please change "Applications can either fail processing or process messages = with incorrect labels, however they MUST NOT create messages with incorrect= labels" to "Applications MUST fail processing for messages with incorrect = labels and they MUST NOT create messages with incorrect labels". The curre= nt wording is a major security hole in a security specification. Please cl= ose the hole! Also, please consider moving this important semantic requirement to a secti= on other than the terminology section, in which it is likely to be overlook= ed. 2. Basic COSE Structure Readers could be misled by the very general wording of this section into th= inking that COSE_Key structures are COSE Messages, as defined in this secti= on. Saying explicitly that a COSE_Key is not a COSE Message would help eli= minate this potential source of confusion. One of the places that I was confused in this way was the text "The followi= ng CDDL fragment identifies all of the top level messages defined in this d= ocument". And yet even though COSE_Key is a top-level data structure, it w= asn't in the list. 3. Header Parameters In "Applications SHOULD perform the same checks that the labels appearing i= n the protected and unprotected headers are unique as well", change the "SH= OULD" to "MUST". This is the same security hole as in 1.4, which needs to = be closed. Then delete the then-superfluous sentence: "If the message is n= ot rejected as malformed, attributes MUST be obtained from the protected bu= cket before they are obtained from the unprotected bucket." The following sentence seems garbled or as if it's missing word(s) near "ge= neric": "It uses forward references to a group definition of headers for ge= neric and algorithms." Please revise. In the following text, I can't tell what "; Algorithm_Headers," is intended= to mean. Is it a comment on either the previous or subsequent line? If s= o, maybe move it onto the line. header_map =3D { Generic_Headers, ; Algorithm_Headers, * label =3D> values } 4.4. Signing and Verification Process In the following sentence, I can't work out what "the appropriate authoriza= tion is done" refers to: "In addition to performing the signature verificat= ion, one must also perform the appropriate checks to ensure that the key is= correctly paired with the signing identity and that the appropriate author= ization is done." Please clarify. 5.3. Encryption Algorithm for AEAD algorithms This instruction is ambiguous because it doesn't say how the key is represe= nted: "For recipients of the message, recursively perform the encryption al= gorithm for that recipient, using the encryption key as the plain text". I= suspect "encryption key" should be changed to "encryption key represented = as a COSE_Key structure". This same language also occurs in 5.4. 7.1. COSE Key Common Parameters Change either the order of the parameters in Table 3 or the order of their = descriptions afterwards so that they are presented in the same order in bot= h places. 11.2. Context Information Structure In the AlgorithmID description, it should probably say that the AlgorithmID= is represented in the same manner as the 'alg' header parameter. 12.2. Key Wrapping Similarly to the ambiguity in 5.3 and 5.4, the text "The plain text to be e= ncrypted is the key from next layer down" doesn't say how the key is repres= ented. In this case, I think it's a raw symmetric key that's encrypted, ri= ght? Please say what it is. A.2. Counter Signature Without Headers Should the "counter signature w/o headers | 9 | bstr" value in Table 27 be = added to the appropriate registry? If the answer is "no", please change "9= " to "TBD". Thanks, -- Mike --_000_SN1PR0301MB16451B251A1994D541E0ABFFF5540SN1PR0301MB1645_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim – I have upd= ated https://github.com/cose-wg/cose-spec/pull/161 to remove the two propose= d changes that you disagreed with.  Unless you weren’t done read= ing the pull request changes, this should now be ready to merge.=

 

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

 

From: Mike Jones
Sent: Sunday, June 12, 2016 11:43 PM
To: cose@ietf.org
Subject: WGLC comments from Mike Jones on draft-ietf-cose-msg-12

 

I’ll say up front that this spec is much impro= ved since the last time I did a full read through.  Good progress.

 

Substantive comments meriting working group visibili= ty are in this note.  Corrections to grammatical, punctuation, and con= sistency nits are contained in the accompanying GitHub pull request, https://github.co= m/cose-wg/cose-spec/pull/161, which (lightly) touches 160 lines.

 

=3D=3D=3D=3D

 

Document Title:

Change “CBOR Encoded Message Syntax” to = “CBOR Object Signing and Encryption (COSE)” so that the title c= ontains and explains the intended acronym for the work.

 

1.4.  CBOR Related Terminology

Please change “Applications can either fail pr= ocessing or process messages with incorrect labels, however they MUST NOT c= reate messages with incorrect labels” to “Applications MUST fai= l processing for messages with incorrect labels and they MUST NOT create messages with incorrect labels”.  The curr= ent wording is a major security hole in a security specification.  Ple= ase close the hole!

 

Also, please consider moving this important semantic= requirement to a section other than the terminology section, in which it i= s likely to be overlooked.

 

2.  Basic COSE Structure

Readers could be misled by the very general wording = of this section into thinking that COSE_Key structures are COSE Messages, a= s defined in this section.  Saying explicitly that a COSE_Key is not a= COSE Message would help eliminate this potential source of confusion.

 

One of the places that I was confused in this way wa= s the text “The following CDDL fragment identifies all of the top lev= el messages defined in this document”.  And yet even though COSE= _Key is a top-level data structure, it wasn’t in the list.

 

3.  Header Parameters

 

In “Applications SHOULD perform the same check= s that the labels appearing in the protected and unprotected headers are un= ique as well”, change the “SHOULD” to “MUST”.=   This is the same security hole as in 1.4, which needs to be closed.&= nbsp; Then delete the then-superfluous sentence: “If the message is not re= jected as malformed, attributes MUST be obtained from the protected bucket = before they are obtained from the unprotected bucket.”

 

The following sentence seems garbled or as if itR= 17;s missing word(s) near “generic”: “It uses forward ref= erences to a group definition of headers for generic and algorithms.”=   Please revise.

 

In the following text, I can’t tell what ̶= 0;; Algorithm_Headers,” is intended to mean.  Is it a comment on= either the previous or subsequent line?  If so, maybe move it onto th= e line.

 

header_map =3D {

    Generic_Headers,

    ; Algorithm_Headers,

    * label =3D> values=

}

 

4.4.  Signing and Verification Process

In the following sentence, I can’t work out wh= at “the appropriate authorization is done” refers to: “In= addition to performing the signature verification, one must also perform t= he appropriate checks to ensure that the key is correctly paired with the signing identity and that the appropriate authorization is= done.”  Please clarify.

 

5.3.  Encryption Algorithm for AEAD algorithms<= o:p>

This instruction is ambiguous because it doesn’= ;t say how the key is represented: “For recipients of the message, re= cursively perform the encryption algorithm for that recipient, using the en= cryption key as the plain text”.  I suspect “encryption key” should be changed to “encryption key represented as a COS= E_Key structure”.  This same language also occurs in 5.4.

 

7.1.  COSE Key Common Parameters

Change either the order of the parameters in Table 3= or the order of their descriptions afterwards so that they are presented i= n the same order in both places.

 

11.2.  Context Information Structure=

In the AlgorithmID description, it should probably s= ay that the AlgorithmID is represented in the same manner as the ‘alg= ’ header parameter.

 

12.2.  Key Wrapping

Similarly to the ambiguity in 5.3 and 5.4, the text = “The plain text to be encrypted is the key from next layer down”= ; doesn’t say how the key is represented.  In this case, I think= it’s a raw symmetric key that’s encrypted, right?  Please say what it is.

 

A.2.  Counter Signature Without Headers

Should the “counter signature w/o headers | 9 = | bstr” value in Table 27 be added to the appropriate registry? = If the answer is “no”, please change “9” to “= ;TBD”.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Thanks,

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

 

 

--_000_SN1PR0301MB16451B251A1994D541E0ABFFF5540SN1PR0301MB1645_-- From nobody Fri Jun 17 00:10:19 2016 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FDD12B019; Fri, 17 Jun 2016 00:10:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160617071014.19121.67418.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2016 00:10:14 -0700 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-13.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 07:10:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption of the IETF. Title : COSE: A Message Based Security Solution for CBOR Author : Jim Schaad Filename : draft-ietf-cose-msg-13.txt Pages : 115 Date : 2016-06-17 Abstract: Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have the basic security services defined for this data format. This document defines the CBOR Object Signing and Encyption (COSE) specification. This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization. This specifiction additionally specifies how to representat cryptographic keys using CBOR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 17 00:18:16 2016 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 7E4C512D504 for ; Fri, 17 Jun 2016 00:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 8BvGziwS-33L for ; Fri, 17 Jun 2016 00:18:13 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D5B12D501 for ; Fri, 17 Jun 2016 00:18:13 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id C973F38EFB for ; Fri, 17 Jun 2016 00:18:12 -0700 (PDT) From: "Jim Schaad" To: References: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> In-Reply-To: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2016 00:18:12 -0700 Message-ID: <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHKX8vhiluIuEjDLHw/pgEUJ1SG/5/8ELgg Content-Language: en-us Archived-At: Subject: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt 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, 17 Jun 2016 07:18:14 -0000 This draft responds to the vast majority of the last call comments that = have been received. Mail about outstanding issues was sent at the time = the pull requests were created but no responses have been received. I believe that any remaining issues could be treated as IETF last call = comments or can be dealt with as the same time that AD comments are = dealt with. With this in mind, I would request that the chairs review = the document for advancement. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, June 17, 2016 12:10 AM > To: Jim Schaad > Subject: New Version Notification for draft-ietf-cose-msg-13.txt >=20 >=20 > A new version of I-D, draft-ietf-cose-msg-13.txt has been successfully = submitted > by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-ietf-cose-msg > Revision: 13 > Title: COSE: A Message Based Security Solution for CBOR > Document date: 2016-06-17 > Group: cose > Pages: 115 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-13.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-13 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-msg-13 >=20 > Abstract: > Concise Binary Object Representation (CBOR) is data format designed > for small code size and small message size. There is a need for = the > ability to have the basic security services defined for this data > format. This document defines the CBOR Object Signing and = Encyption > (COSE) specification. This specification describes how to create = and > process signature, message authentication codes and encryption = using > CBOR for serialization. This specifiction additionally specifies = how > to representat cryptographic keys using CBOR. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Fri Jun 17 14:12:20 2016 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 6EBBC12DAE2; Fri, 17 Jun 2016 14:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 w_gf7LMKox5r; Fri, 17 Jun 2016 14:12:02 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E236012D178; Fri, 17 Jun 2016 14:12:01 -0700 (PDT) Received: from mfilter31-d.gandi.net (mfilter31-d.gandi.net [217.70.178.162]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 342E5C5A50; Fri, 17 Jun 2016 23:12:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter31-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter31-d.gandi.net (mfilter31-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Zi4rXm0pti56; Fri, 17 Jun 2016 23:11:58 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 986F5C5A4E; Fri, 17 Jun 2016 23:11:57 +0200 (CEST) Message-ID: <5764679C.5010608@tzi.org> Date: Fri, 17 Jun 2016 23:11:56 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "ace@ietf.org" , "core@ietf.org WG" , "cose@ietf.org" , dtls-iot@ietf.org, "t2trg@irtf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [COSE] Constrained Node/Network Cluster @ IETF96: DRAFT 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: Fri, 17 Jun 2016 21:12:04 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF96. Remember that there is still quite some potential for changes. Apart from COSE on PLUS (ouch), and the maybe more personal conflicts of ACE on QUIC and 6LO on ARTAREA, I'm not seeing a lot of hurt this time. Moves due to other conflict avoidance may make this worse, though. All times are CEST (UTC-0200). (The browser timezone function is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Grüße, Carsten MONDAY, July 18, 2016 1000-1230 Morning Session I Potsdam II ART artarea Applications and Real-Time Area Open Meeting - Combined with DISPATCH Potsdam III INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG 1400-1530 Afternoon Session I Potsdam II ART httpbis Hypertext Transfer Protocol WG Bellevue INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Potsdam I INT homenet Home Networking WG Tiergarten SEC oauth Web Authorization Protocol WG Ch_burg I SEC openpgp Open Specification for Pretty Good Privacy WG Potsdam III TSV tsvarea Transport Area Open Meeting 1540-1740 Afternoon Session II Ch_burg II/III INT *** lpwan Low-Power Wide Area Networks BOF Potsdam II SEC acme Automated Certificate Management Environment WG 1800-2000 Afternoon Session III Potsdam I IRTF maprg Proposed Measurement and Analysis for Protocols Research Group Potsdam II OPS anima Autonomic Networking Integrated Model and Approach WG Schoeneberg RTG bier Bit Indexed Explicit Replication WG Bellevue RTG detnet Deterministic Networking WG Potsdam III SEC lurk Limited Use of Remote Keys BOF TUESDAY, July 19, 2016 1000-1230 Morning Session I Potsdam I INT 6man IPv6 Maintenance WG Potsdam III SEC tls Transport Layer Security WG Bellevue TSV rmcat RTP Media Congestion Avoidance Techniques WG 1400-1600 Afternoon Session I Ch_burg II/III ART *** core Constrained RESTful Environments WG Bellevue SEC tokbind Token Binding WG Potsdam I TSV l4s Low Latency Low Loss Scalable throughput BOF 1620-1820 Afternoon Session II Potsdam II ART uta Using TLS in Applications WG Schoeneberg ART webpush Web-Based Push Notifications WG Potsdam III IRTF*** t2trg Thing-to-Thing Potsdam I RTG rtgarea Routing Area Open Meeting Ch_burg II/III TSV tcpinc TCP Increased Security WG WEDNESDAY, July 20, 2016 1000-1230 Morning Session I Bellevue SEC *** ace Authentication and Authorization for Constrained Environments WG Ch_burg I SEC curdle CURves, Deprecating and a Little more Encryption WG Potsdam I TSV quic QUIC BOF 1400-1530 Afternoon Session I Ch_burg II/III INT dnssd Extensions for Scalable DNS Service Discovery WG Potsdam III IRTF cfrg Crypto Forum 1550-1720 Afternoon Session II Schoeneberg RTG *** roll Routing Over Low power and Lossy networks WG Lincke SEC oauth Web Authorization Protocol WG Ch_burg II/III TSV tsvwg Transport Area Working Group WG THURSDAY, July 21, 2016 1000-1230 Morning Session I Schoeneberg ART ice Interactive Connectivity Establishment WG Ch_burg I SEC *** cose CBOR Object Signing and Encryption WG - 11:30-12:30 Potsdam I TSV plus Path Layer UDP Substrate BOF 1400-1600 Afternoon Session I Bellevue INT its Intelligent Transportation Systems BOF Potsdam I OPS v6ops IPv6 Operations WG Potsdam III SEC saag Security Area Open Meeting 1620-1820 Afternoon Session II Tiergarten ART *** core Constrained RESTful Environments WG Potsdam III OPS anima Autonomic Networking Integrated Model and Approach WG Potsdam II RTG babel Babel routing protocol WG 1830-1930 Afternoon Session III Potsdam III INT intarea Internet Area Working Group WG Bellevue TSV taps Transport Services WG FRIDAY, July 22, 2016 1000-1200 Morning Session I Bellevue ART httpbis Hypertext Transfer Protocol WG Ch_burg II/III TSV tsvwg Transport Area Working Group WG 1220-1320 Afternoon Session I Schoeneberg INT *** lwig Light-Weight Implementation Guidance WG Ch_burg I SEC spasm Some PKIX and SMIME WG From nobody Sat Jun 18 06:34:26 2016 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 7863A12D1B9 for ; Sat, 18 Jun 2016 06:34:24 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.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 PDzKp-Qv4xrE for ; Sat, 18 Jun 2016 06:34:21 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id B6C2412D1B7 for ; Sat, 18 Jun 2016 06:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1466256858; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=erkyw+XhaNb5Bf5qhfVlyHhjEtrcyNkVzoDFrDv01aw=; b=p9SF7uRxH+GBF/cS/Z7Ha0q2c2w9uk4ZMmyr+fTpDcTldI7yzLHETHsbZh0qvGqCLVFZWEtqJhUPpDor9+4WtUSGYvWyKmdSdPHelGAeVVN0+FiJA57LI9lp2mbFb/1ZQTKUtr8Qpbpr9phfe979tg6T8fhoCA7kNF5CibPi1kE= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R131e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03310; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; TI=SMTPD_----4wInNyn_1466256850; Received: from 30.39.38.126(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sat, 18 Jun 2016 21:34:13 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sat, 18 Jun 2016 21:34:09 +0800 From: "Kepeng Li" To: Jim Schaad , Message-ID: Thread-Topic: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt References: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> In-Reply-To: <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt 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, 18 Jun 2016 13:34:24 -0000 Just some questions for clarification. 1. About the document title, COSE: A Message Based Security Solution for CBOR, why don=A1=AFt we use something like this: COSE: CBOR Object Signing and Encyption specification? 2. Section 13, section title is just "keys=A1=B0, should we be more specific? Maybe it is too genetic to say just keys. We have talked about keys in several sections. We need to diffentiate this section with other places from the title. 3. Section 17, "implementation status=A1=B0, this is an informative section. Should we move it to appendix? Kind Regards Kepeng (Individual) =D4=DA 17/6/16 3:18 pm=A3=AC "Jim Schaad" =D0=B4=C8=EB: >This draft responds to the vast majority of the last call comments that >have been received. Mail about outstanding issues was sent at the time >the pull requests were created but no responses have been received. > >I believe that any remaining issues could be treated as IETF last call >comments or can be dealt with as the same time that AD comments are dealt >with. With this in mind, I would request that the chairs review the >document for advancement. > >Jim > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, June 17, 2016 12:10 AM >> To: Jim Schaad >> Subject: New Version Notification for draft-ietf-cose-msg-13.txt >>=20 >>=20 >> A new version of I-D, draft-ietf-cose-msg-13.txt has been successfully >>submitted >> by Jim Schaad and posted to the IETF repository. >>=20 >> Name: draft-ietf-cose-msg >> Revision: 13 >> Title: COSE: A Message Based Security Solution for CBOR >> Document date: 2016-06-17 >> Group: cose >> Pages: 115 >> URL: =20 >>https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-13.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-13 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-msg-13 >>=20 >> Abstract: >> Concise Binary Object Representation (CBOR) is data format designed >> for small code size and small message size. There is a need for the >> ability to have the basic security services defined for this data >> format. This document defines the CBOR Object Signing and Encyption >> (COSE) specification. This specification describes how to create and >> process signature, message authentication codes and encryption using >> CBOR for serialization. This specifiction additionally specifies how >> to representat cryptographic keys using CBOR. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >>submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat > > >_______________________________________________ >COSE mailing list >COSE@ietf.org >https://www.ietf.org/mailman/listinfo/cose From nobody Sat Jun 18 09:24:49 2016 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 5D57212D73A for ; Sat, 18 Jun 2016 09:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 rtzerJH7M_ei for ; Sat, 18 Jun 2016 09:24:46 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2ECE12D6AA for ; Sat, 18 Jun 2016 09:24:39 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id EA57138EF0; Sat, 18 Jun 2016 09:24:38 -0700 (PDT) From: "Jim Schaad" To: "'Kepeng Li'" , References: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> In-Reply-To: Date: Sat, 18 Jun 2016 09:24:38 -0700 Message-ID: <007701d1c97d$e9258420$bb708c60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHKX8vhiluIuEjDLHw/pgEUJ1SG/wHqgDMoAnvLMY+f2wj/gA== Content-Language: en-us Archived-At: Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt 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, 18 Jun 2016 16:24:48 -0000 > -----Original Message----- > From: Kepeng Li [mailto:kepeng.lkp@alibaba-inc.com] > Sent: Saturday, June 18, 2016 6:34 AM > To: Jim Schaad ; cose@ietf.org > Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt > > Just some questions for clarification. > > 1. About the document title, COSE: A Message Based Security Solution for CBOR, > why don$B!G(Bt we use something like this: COSE: CBOR Object Signing and Encyption > specification? I would prefer to use a title that is representative of what the document is supposed to do. It is possible that the second title will be required but it is not my preference. > > 2. Section 13, section title is just "keys$B!H(B, should we be more specific? > Maybe it is too genetic to say just keys. We have talked about keys in several > sections. We need to diffentiate this section with other places from the title. Matching the other sections, the title should probably be "Key Objects". > > 3. Section 17, "implementation status$B!H(B, this is an informative section. > Should we move it to appendix? This section is removed before publication - so it's location is not all of that significant. Jim > > Kind Regards > Kepeng > (Individual) > > $B:_(B 17/6/16 3:18 pm$B!$(B "Jim Schaad" $B > >This draft responds to the vast majority of the last call comments that > >have been received. Mail about outstanding issues was sent at the time > >the pull requests were created but no responses have been received. > > > >I believe that any remaining issues could be treated as IETF last call > >comments or can be dealt with as the same time that AD comments are > >dealt with. With this in mind, I would request that the chairs review > >the document for advancement. > > > >Jim > > > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Friday, June 17, 2016 12:10 AM > >> To: Jim Schaad > >> Subject: New Version Notification for draft-ietf-cose-msg-13.txt > >> > >> > >> A new version of I-D, draft-ietf-cose-msg-13.txt has been > >>successfully submitted by Jim Schaad and posted to the IETF > >>repository. > >> > >> Name: draft-ietf-cose-msg > >> Revision: 13 > >> Title: COSE: A Message Based Security Solution for CBOR > >> Document date: 2016-06-17 > >> Group: cose > >> Pages: 115 > >> URL: > >>https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-13.txt > >> Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > >> Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-13 > >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-13 > >> > >> Abstract: > >> Concise Binary Object Representation (CBOR) is data format designed > >> for small code size and small message size. There is a need for the > >> ability to have the basic security services defined for this data > >> format. This document defines the CBOR Object Signing and Encyption > >> (COSE) specification. This specification describes how to create and > >> process signature, message authentication codes and encryption using > >> CBOR for serialization. This specifiction additionally specifies how > >> to representat cryptographic keys using CBOR. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >>submission until the htmlized version and diff are available at > >>tools.ietf.org. > >> > >> The IETF Secretariat > > > > > >_______________________________________________ > >COSE mailing list > >COSE@ietf.org > >https://www.ietf.org/mailman/listinfo/cose From nobody Sat Jun 18 12:52:01 2016 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 A5A9A12D84B for ; Sat, 18 Jun 2016 12:51:59 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 aQE4P-PCrx54 for ; Sat, 18 Jun 2016 12:51:57 -0700 (PDT) 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 1CCC512D84A for ; Sat, 18 Jun 2016 12:51:56 -0700 (PDT) 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 u5IJoN6n026021; Sat, 18 Jun 2016 21:50:23 +0200 (CEST) Received: from roku (p5B31420D.dip0.t-ipconnect.de [91.49.66.13]) (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 3rX75C0K7CzDhfG; Sat, 18 Jun 2016 21:50:22 +0200 (CEST) Date: Sat, 18 Jun 2016 21:50:22 +0200 From: Carsten Bormann To: Jim Schaad Message-ID: <2702aef8-003a-461c-9807-9d2dc43bf124@roku> In-Reply-To: <007701d1c97d$e9258420$bb708c60$@augustcellars.com> References: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> <007701d1c97d$e9258420$bb708c60$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5765a5fe_6b8b4567_1ef4" Archived-At: Cc: 'Kepeng Li' , "\"=?utf-8?Q?cose=40ietf.org?=\"" Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt 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, 18 Jun 2016 19:51:59 -0000 --5765a5fe_6b8b4567_1ef4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Jim, > COSE The rfc Editor is going to insist on expanding that abbreviation anyway. = Actually, I don't mind the result of doing that to your title. =20 Gr=C3=BC=C3=9Fe, Carsten =20 --5765a5fe_6b8b4567_1ef4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Jim,

COSE

The rfc Editor is going to insist on expanding tha= t abbreviation anyway. Actually, I don't mind the result of doing that to= your title.

Gr=C3=BC=C3=9Fe, Carsten

On 18 Jun 2016 18:24, Jim Schaad wrote:

=09
&=2313;
-----Original Me= ssage-----&=2313;
=46rom: Kepeng Li =5Bmailto:kepeng.lkp=40alibaba-in= c.com=5D&=2313;
Sent: Saturday, June 18, 2016 6:34 AM&=2313;
To: = Jim Schaad <ietf=40augustcellars.com>; cose=40ietf.org&=2313;
S= ubject: Re: =5BCOSE=5D =46W: New Version Notification for&=2313;
draft-ietf-cose-msg-13.txt&=2313;
&=2313;
Just some questions for clarification.&=2313;
&=2313;=
1. About the document title, COSE: A Message Based Security Solution= for&=2313;
CBOR,&=2313;
why don=E2=80=99t we use something like this: COSE: CBOR Object Signing = and&=2313;
Encyption&=2313;
specification=3F&=2313;
&=2313;
I would prefer= to use a title that is representative of what the document is&=2313;
supposed to do. It is possible that the second title will be required b= ut&=2313;
it is not my preference.&=2313;
&=2313;
&=2313;
2. Section 13, section title is just =22ke= ys=E2=80=9C, should we be more specific=3F&=2313;
Maybe it is too gen= etic to say just keys. We have talked about keys in&=2313;
several&=2313;
sections. We need to = diffentiate this section with other places from the&=2313;
title.&=2313;
&=2313;
Matching the other sections, the title s= hould probably be =22Key Objects=22.&=2313;
&=2313;
&=2313;
3. Section 17, =22implementation status=E2=80= =9C, this is an informative section.&=2313;
Should we move it to appe= ndix=3F&=2313;
&=2313;
This section is removed befor= e publication - so it's location is not all of&=2313;
that significan= t.&=2313;
&=2313;
Jim&=2313;
&=2313;
&=2313;
Kind Regards&=2313;
Kepeng&=2313;
(Individual= )&=2313;
&=2313;
=E5=9C=A8 17/6/16 3:18 pm=EF=BC=8C =22Jim Schaad= =22 <ietf=40augustcellars.com> =E5=86=99=E5=85=A5:&=2313;
&=231= 3;
This draft responds to the vast majo= rity of the last call comments that&=2313;
have been received. Mail = about outstanding issues was sent at the time&=2313;
the pull request= s were created but no responses have been received.&=2313;
&=2313;I believe that any remaining issues could be treated as IET=46 last cal= l&=2313;
comments or can be dealt with as the same time that AD comme= nts are&=2313;
dealt with. With this in mind, I would request that t= he chairs review&=2313;
the document for advancement.&=2313;
&=23= 13;
Jim&=2313;
&=2313;
&=2313;
-----Original Message-----&=2313;
=46rom: internet-drafts=40ietf.= org =5Bmailto:internet-drafts=40ietf.org=5D&=2313;
Sent: =46riday, Ju= ne 17, 2016 12:10 AM&=2313;
To: Jim Schaad <ietf=40augustcellars.c= om>&=2313;
Subject: New Version Notification for draft-ietf-cose-m= sg-13.txt&=2313;
&=2313;
&=2313;
A new version of I-D, draft-= ietf-cose-msg-13.txt has been&=2313;
successfully submitted by Jim S= chaad and posted to the IET=46&=2313;
repository.&=2313;
&=2313;<= br/>Name: draft-ietf-cose-msg&=2313;
Revision: 13&=2313;
Title: = COSE: A Message Based Security Solution for CBOR&=2313;
Document dat= e: 2016-06-17&=2313;
Group: cose&=2313;
Pages: 115&=2313;
U= RL:&=2313;
https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-1= 3.txt&=2313;
Status: https://datatracker.ietf.org/doc/draft-i= etf-cose-msg/&=2313;
Htmlized: https://tools.ietf.org/html/draf= t-ietf-cose-msg-13&=2313;
Diff:&=2313;
=
https://www.ietf.org/rfcdiff=3Furl2=3Ddraft-ietf-cose-msg-13= &=2313;
<= blockquote type=3D=22cite=22>&=2313;
Abstract:&=2313;
Concise Bin= ary Object Representation (CBOR) is data format designed&=2313;
for s= mall code size and small message size. There is a need for the&=2313;ability to have the basic security services defined for this data&=2313= ;
format. This document defines the CBOR Object Signing and Encyptio= n&=2313;
(COSE) specification. This specification describes how to c= reate&=2313;
and&=2313;
process signature, message authentication codes and encryp= tion using&=2313;
CBOR for serialization. This specifiction addition= ally specifies&=2313;
how&=231= 3;
to representat cryptographic keys using CBOR.&=23= 13;
&=2313;
&=2313;
&=2313;
&=2313;
Please note that = it may take a couple of minutes from the time of&=2313;
submission u= ntil the htmlized version and diff are available at&=2313;
tools.ietf= .org.&=2313;
&=2313;
The IET=46 Secretariat&=2313;
&=2313;
&=2313;
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F&=2313;
COSE mailing list&=2313;
COSE=40ietf.or= g&=2313;
https://www.ietf.org/mailman/listinfo/cose&=2313;
&=2313;
&=2313;
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F&=2313;
COSE mailing list&=2313;<= br/>COSE=40ietf.org&=2313;
https://www.ietf.org/mailman/listinfo/cose= &=2313;
&=2313;
--5765a5fe_6b8b4567_1ef4-- From nobody Sat Jun 18 14:00:36 2016 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 469AE12D984 for ; Sat, 18 Jun 2016 14:00:34 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 IdSpPPbRmMiI for ; Sat, 18 Jun 2016 14:00:32 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E394112D983 for ; Sat, 18 Jun 2016 14:00:31 -0700 (PDT) Received: from hebrews (static-50-39-87-30.bvtn.or.frontiernet.net [50.39.87.30]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 714DC2C9BE; Sat, 18 Jun 2016 14:00:30 -0700 (PDT) From: "Jim Schaad" To: "'Carsten Bormann'" References: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> <007701d1c97d$e9258420$bb708c60$@augustcellars.com> <2702aef8-003a-461c-9807-9d2dc43bf124@roku> In-Reply-To: <2702aef8-003a-461c-9807-9d2dc43bf124@roku> Date: Sat, 18 Jun 2016 14:00:19 -0700 Message-ID: <009201d1c9a4$72b50320$581f0960$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0093_01D1C969.C65A70E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHKX8vhiluIuEjDLHw/pgEUJ1SG/wHqgDMoAnvLMY8BPiMlgwF7MN2Hn8WL5ZA= Content-Language: en-us Archived-At: Cc: 'Kepeng Li' , cose@ietf.org Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt 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, 18 Jun 2016 21:00:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0093_01D1C969.C65A70E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As I have said, I might lose that battle, but I think that expanding the = acronyms in the title is actually counterproductive and I am willing to = try and fight it. I intend to bring it up as an issue to the right = people in Berlin. =20 Jim =20 =20 From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Saturday, June 18, 2016 12:50 PM To: Jim Schaad Cc: 'Kepeng Li' ; " cose@ietf.org " = Subject: Re: [COSE] FW: New Version Notification for = draft-ietf-cose-msg-13.txt =20 Hi Jim, COSE The rfc Editor is going to insist on expanding that abbreviation anyway. = Actually, I don't mind the result of doing that to your title.=20 Gr=C3=BC=C3=9Fe, Carsten=20 On 18 Jun 2016 18:24, Jim Schaad wrote:=20 -----Original Message-----=20 From: Kepeng Li [mailto:kepeng.lkp@alibaba-inc.com]=20 Sent: Saturday, June 18, 2016 6:34 AM=20 To: Jim Schaad = >; cose@ietf.org =20 Subject: Re: [COSE] FW: New Version Notification for=20 draft-ietf-cose-msg-13.txt=20 Just some questions for clarification.=20 1. About the document title, COSE: A Message Based Security Solution for = CBOR,=20 why don=E2=80=99t we use something like this: COSE: CBOR Object Signing = and=20 Encyption=20 specification?=20 I would prefer to use a title that is representative of what the = document is=20 supposed to do. It is possible that the second title will be required = but=20 it is not my preference.=20 2. Section 13, section title is just "keys=E2=80=9C, should we be more = specific?=20 Maybe it is too genetic to say just keys. We have talked about keys in=20 several=20 sections. We need to diffentiate this section with other places from the = title.=20 Matching the other sections, the title should probably be "Key Objects". = 3. Section 17, "implementation status=E2=80=9C, this is an informative = section.=20 Should we move it to appendix?=20 This section is removed before publication - so it's location is not all = of=20 that significant.=20 Jim=20 Kind Regards=20 Kepeng=20 (Individual)=20 =E5=9C=A8 17/6/16 3:18 pm=EF=BC=8C "Jim Schaad" > =E5=86=99=E5=85=A5:=20 This draft responds to the vast majority of the last call comments that=20 have been received. Mail about outstanding issues was sent at the time=20 the pull requests were created but no responses have been received.=20 I believe that any remaining issues could be treated as IETF last call=20 comments or can be dealt with as the same time that AD comments are=20 dealt with. With this in mind, I would request that the chairs review=20 the document for advancement.=20 Jim=20 -----Original Message-----=20 From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 Sent: Friday, June 17, 2016 12:10 AM=20 To: Jim Schaad > = Subject: New Version Notification for draft-ietf-cose-msg-13.txt=20 A new version of I-D, draft-ietf-cose-msg-13.txt has been=20 successfully submitted by Jim Schaad and posted to the IETF=20 repository.=20 Name: draft-ietf-cose-msg=20 Revision: 13=20 Title: COSE: A Message Based Security Solution for CBOR=20 Document date: 2016-06-17=20 Group: cose=20 Pages: 115=20 URL:=20 https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-13.txt=20 Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/=20 Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-13=20 Diff:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-msg-13=20 Abstract:=20 Concise Binary Object Representation (CBOR) is data format designed=20 for small code size and small message size. There is a need for the=20 ability to have the basic security services defined for this data=20 format. This document defines the CBOR Object Signing and Encyption=20 (COSE) specification. This specification describes how to create=20 and=20 process signature, message authentication codes and encryption using=20 CBOR for serialization. This specifiction additionally specifies=20 how=20 to representat cryptographic keys using CBOR.=20 Please note that it may take a couple of minutes from the time of=20 submission until the htmlized version and diff are available at=20 tools.ietf.org.=20 The IETF Secretariat=20 _______________________________________________=20 COSE mailing list=20 COSE@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose=20 _______________________________________________=20 COSE mailing list=20 COSE@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose=20 ------=_NextPart_000_0093_01D1C969.C65A70E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

As I have = said, I might lose that battle, but I think that expanding the acronyms = in the title is actually counterproductive and I am willing to try and = fight it.=C2=A0 I intend to bring it up as an issue to the right people = in Berlin.

 

Jim

 

 

From:<= /b> = Carsten Bormann [mailto:cabo@tzi.org]
Sent: Saturday, June = 18, 2016 12:50 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: 'Kepeng Li' = <kepeng.lkp@alibaba-inc.com>; " cose@ietf.org " = <cose@ietf.org>
Subject: Re: [COSE] FW: New Version = Notification for = draft-ietf-cose-msg-13.txt

 

Hi Jim,

COSE


The rfc Editor is going to insist on expanding = that abbreviation anyway. Actually, I don't mind the result of doing = that to your title.

Gr=C3=BC=C3=9Fe, Carsten =


On 18 Jun 2016 18:24, Jim Schaad = wrote:




-----Original Message-----
From: Kepeng Li [mailto:kepeng.lkp@alibaba-inc.= com]
Sent: Saturday, June 18, 2016 6:34 AM
To: Jim Schaad = <ietf@augustcellars.com>; = cose@ietf.org
Subject: Re: = [COSE] FW: New Version Notification for

draft-ietf-cose-msg-13.txt =


Just some questions for clarification.

1. = About the document title, COSE: A Message Based Security Solution for =

CBOR, =

why = don=E2=80=99t we use something like this: COSE: CBOR Object Signing and =

Encyption =

specification?


I would prefer to use a title that is = representative of what the document is
supposed to do. It is = possible that the second title will be required but
it is not my = preference.



2. Section 13, section title is just = "keys=E2=80=9C, should we be more specific?
Maybe it is too = genetic to say just keys. We have talked about keys in =

several =

sections. We need to diffentiate this section with = other places from the

title.

Matching the other sections, the title = should probably be "Key Objects". =



3. Section 17, "implementation = status=E2=80=9C, this is an informative section.
Should we move it = to appendix?


This = section is removed before publication - so it's location is not all of =
that significant.

Jim



Kind Regards
Kepeng
(Individual) =

=E5=9C=A8 17/6/16 = 3:18 pm=EF=BC=8C = "Jim Schaad" <ietf@augustcellars.com> = =E5=86=99=E5=85=A5: =


This = draft responds to the vast majority of the last call comments that =
have been received. Mail about outstanding issues was sent at the = time
the pull requests were created but no responses have been = received.

I believe that any remaining issues could be treated = as IETF last call
comments or can be dealt with as the same time = that AD comments are
dealt with. With this in mind, I would request = that the chairs review
the document for advancement.

Jim =



-----Original Message-----
From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org<= /a>]
Sent: Friday, June 17, 2016 12:10 AM
To: Jim Schaad <ietf@augustcellars.com> =
Subject: New Version Notification for draft-ietf-cose-msg-13.txt =


A new version of I-D, draft-ietf-cose-msg-13.txt has been =
successfully submitted by Jim Schaad and posted to the IETF =
repository.

Name: draft-ietf-cose-msg
Revision: 13 =
Title: COSE: A Message Based Security Solution for CBOR
Document = date: 2016-06-17
Group: cose
Pages: 115
URL:
= https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-13.txt =
Status: https://da= tatracker.ietf.org/doc/draft-ietf-cose-msg/
Htmlized: https://tools= .ietf.org/html/draft-ietf-cose-msg-13
Diff: =

https= ://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-msg-13 =


Abstract:
Concise Binary Object Representation = (CBOR) is data format designed
for small code size and small message = size. There is a need for the
ability to have the basic security = services defined for this data
format. This document defines the = CBOR Object Signing and Encyption
(COSE) specification. This = specification describes how to create =

and

process signature, message authentication codes and = encryption using
CBOR for serialization. This specifiction = additionally specifies =

how

to = representat cryptographic keys using CBOR.




Please = note that it may take a couple of minutes from the time of =
submission until the htmlized version and diff are available at =
tools.ietf.org.

The IETF Secretariat =



_______________________________________________=
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 =

------=_NextPart_000_0093_01D1C969.C65A70E0-- From nobody Sun Jun 19 11:07:49 2016 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 5B5A312D67F for ; Sun, 19 Jun 2016 11:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 1xo7FaNWZocs for ; Sun, 19 Jun 2016 11:07:45 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BEA12D678 for ; Sun, 19 Jun 2016 11:07:45 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id BAD5D2CA06; Sun, 19 Jun 2016 11:07:44 -0700 (PDT) From: "Jim Schaad" To: "'Kepeng Li'" , References: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> <007701d1c97d$e9258420$bb708c60$@augustcellars.com> In-Reply-To: <007701d1c97d$e9258420$bb708c60$@augustcellars.com> Date: Sun, 19 Jun 2016 11:07:44 -0700 Message-ID: <012001d1ca55$7aa2b710$6fe82530$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHKX8vhiluIuEjDLHw/pgEUJ1SG/wHqgDMoAnvLMY8BPiMlg5/Sx4IA Content-Language: en-us Archived-At: Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt 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: Sun, 19 Jun 2016 18:07:48 -0000 I should have read the section rather than just the TOC. The correct section title would be "Key Object Parameters" not "Key Object" as that should be the title for section 7. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Saturday, June 18, 2016 9:25 AM > To: 'Kepeng Li' ; cose@ietf.org > Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt > > > > > -----Original Message----- > > From: Kepeng Li [mailto:kepeng.lkp@alibaba-inc.com] > > Sent: Saturday, June 18, 2016 6:34 AM > > To: Jim Schaad ; cose@ietf.org > > Subject: Re: [COSE] FW: New Version Notification for > draft-ietf-cose-msg-13.txt > > > > Just some questions for clarification. > > > > 1. About the document title, COSE: A Message Based Security Solution > > for > CBOR, > > why don$B!G(Bt we use something like this: COSE: CBOR Object Signing and > Encyption > > specification? > > I would prefer to use a title that is representative of what the document is > supposed to do. It is possible that the second title will be required but it is not > my preference. > > > > > 2. Section 13, section title is just "keys$B!H(B, should we be more specific? > > Maybe it is too genetic to say just keys. We have talked about keys in > several > > sections. We need to diffentiate this section with other places from > > the > title. > > Matching the other sections, the title should probably be "Key Objects". > > > > > 3. Section 17, "implementation status$B!H(B, this is an informative section. > > Should we move it to appendix? > > This section is removed before publication - so it's location is not all of that > significant. > > Jim > > > > > Kind Regards > > Kepeng > > (Individual) > > > > $B:_(B 17/6/16 3:18 pm$B!$(B "Jim Schaad" $B > > > >This draft responds to the vast majority of the last call comments > > >that have been received. Mail about outstanding issues was sent at > > >the time the pull requests were created but no responses have been received. > > > > > >I believe that any remaining issues could be treated as IETF last > > >call comments or can be dealt with as the same time that AD comments > > >are dealt with. With this in mind, I would request that the chairs > > >review the document for advancement. > > > > > >Jim > > > > > > > > >> -----Original Message----- > > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > >> Sent: Friday, June 17, 2016 12:10 AM > > >> To: Jim Schaad > > >> Subject: New Version Notification for draft-ietf-cose-msg-13.txt > > >> > > >> > > >> A new version of I-D, draft-ietf-cose-msg-13.txt has been > > >>successfully submitted by Jim Schaad and posted to the IETF > > >>repository. > > >> > > >> Name: draft-ietf-cose-msg > > >> Revision: 13 > > >> Title: COSE: A Message Based Security Solution for CBOR > > >> Document date: 2016-06-17 > > >> Group: cose > > >> Pages: 115 > > >> URL: > > >>https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-13.txt > > >> Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > > >> Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-13 > > >> Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-13 > > >> > > >> Abstract: > > >> Concise Binary Object Representation (CBOR) is data format designed > > >> for small code size and small message size. There is a need for the > > >> ability to have the basic security services defined for this data > > >> format. This document defines the CBOR Object Signing and Encyption > > >> (COSE) specification. This specification describes how to > > >> create > and > > >> process signature, message authentication codes and encryption using > > >> CBOR for serialization. This specifiction additionally > > >> specifies > how > > >> to representat cryptographic keys using CBOR. > > >> > > >> > > >> > > >> > > >> Please note that it may take a couple of minutes from the time of > > >>submission until the htmlized version and diff are available at > > >>tools.ietf.org. > > >> > > >> The IETF Secretariat > > > > > > > > >_______________________________________________ > > >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 From nobody Sun Jun 19 13:23:07 2016 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 E974D12D7D6 for ; Sun, 19 Jun 2016 13:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 Zq9G5uwLN5e6 for ; Sun, 19 Jun 2016 13:23:04 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.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 0786F12D7D1 for ; Sun, 19 Jun 2016 13:23:03 -0700 (PDT) X-AuditID: 1209190c-873ff700000064c6-9c-5766ff25564c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id CD.4B.25798.52FF6675; Sun, 19 Jun 2016 16:23:02 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u5JKN0Z7015670; Sun, 19 Jun 2016 16:23:01 -0400 Received: from [192.168.128.57] (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 u5JKMwdv013949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 19 Jun 2016 16:23:00 -0400 To: Kepeng Li , Jim Schaad , cose@ietf.org References: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> From: Justin Richer Message-ID: Date: Sun, 19 Jun 2016 16:22:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6noqv2Py3c4Ns8M4tpW6eyWqye/p3N 4vL8Igdmj4lvP7J4bJwznc1jyZKfTAHMUVw2Kak5mWWpRfp2CVwZ/1+eZS3YIVWxdMsD1gbG naJdjBwcEgImEjumh3UxcnEICbQxSRzsesoM4WxklPiz7hIbhHObSeJM1yzGLkZODmGBQIlH 37axg9giAukSp569hSpayijR1XAYrIhNQFVi+poWJhCbV8BKYnLrTLAGFqD491XX2EBsUYEY icbbh9khagQlTs58wgJicwpYSBz5/BoszixgJtG1tYsRwpaXaN46m3kCI/8sJC2zkJTNQlK2 gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6hXm5miV5qSukmRlCQckry7GA888brEKMAB6MS D6/F2bRwIdbEsuLK3EOMkhxMSqK8e7pTw4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8B76A1TO m5JYWZValA+TkuZgURLnLdx/OkxIID2xJDU7NbUgtQgmK8PBoSTB++wvUKNgUWp6akVaZk4J QpqJgxNkOA/Q8EcgNbzFBYm5xZnpEPlTjIpS4rzS/4ASAiCJjNI8uF5QEkl4e9j0FaM40CvC vHIgVTzABATX/QpoMBPQYM15ySCDSxIRUlINjEuzX+cciLT/vd7tIduVancvTYvFy52PmB5v 5E36KMe5tr9V8cbz4Ptqj9KEjviryx3k+fr+vUbBg1C9hO9eX7fx3dghFSU4Y/HriJ+tXhXe B5+91Ezx+71QJu+mZlnd0qdv1UKOsAVd36oVcUXgXI/lm/zdUbMlLK894O/SENONSHF8trXn ihJLcUaioRZzUXEiADNvGwj9AgAA Archived-At: Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt 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: Sun, 19 Jun 2016 20:23:06 -0000 I agree with Kepeng and others on the title: "COSE: CBOR Object Signing and Encryption". -- Justin On 6/18/2016 9:34 AM, Kepeng Li wrote: > Just some questions for clarification. > > 1. About the document title, COSE: A Message Based Security Solution for > CBOR, why don’t we use something like this: COSE: CBOR Object Signing and > Encyption specification? > > 2. Section 13, section title is just "keys“, should we be more specific? > Maybe it is too genetic to say just keys. We have talked about keys in > several sections. We need to diffentiate this section with other places > from the title. > > 3. Section 17, "implementation status“, this is an informative section. > Should we move it to appendix? > > Kind Regards > Kepeng > (Individual) > > 在 17/6/16 3:18 pm， "Jim Schaad" 写入: > >> This draft responds to the vast majority of the last call comments that >> have been received. Mail about outstanding issues was sent at the time >> the pull requests were created but no responses have been received. >> >> I believe that any remaining issues could be treated as IETF last call >> comments or can be dealt with as the same time that AD comments are dealt >> with. With this in mind, I would request that the chairs review the >> document for advancement. >> >> Jim >> >> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Friday, June 17, 2016 12:10 AM >>> To: Jim Schaad >>> Subject: New Version Notification for draft-ietf-cose-msg-13.txt >>> >>> >>> A new version of I-D, draft-ietf-cose-msg-13.txt has been successfully >>> submitted >>> by Jim Schaad and posted to the IETF repository. >>> >>> Name: draft-ietf-cose-msg >>> Revision: 13 >>> Title: COSE: A Message Based Security Solution for CBOR >>> Document date: 2016-06-17 >>> Group: cose >>> Pages: 115 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-13.txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >>> Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-13 >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-13 >>> >>> Abstract: >>> Concise Binary Object Representation (CBOR) is data format designed >>> for small code size and small message size. There is a need for the >>> ability to have the basic security services defined for this data >>> format. This document defines the CBOR Object Signing and Encyption >>> (COSE) specification. This specification describes how to create and >>> process signature, message authentication codes and encryption using >>> CBOR for serialization. This specifiction additionally specifies how >>> to representat cryptographic keys using CBOR. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >> >> _______________________________________________ >> 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 From nobody Sun Jun 19 15:31:17 2016 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 4EF7512D84E for ; Sun, 19 Jun 2016 15:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 2LlKFRsUsSEU for ; Sun, 19 Jun 2016 15:31:14 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F14812D6AE for ; Sun, 19 Jun 2016 15:31:14 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 9E2F92CA0A; Sun, 19 Jun 2016 15:31:13 -0700 (PDT) From: "Jim Schaad" To: "'Justin Richer'" , "'Kepeng Li'" , References: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> In-Reply-To: Date: Sun, 19 Jun 2016 15:31:13 -0700 Message-ID: <012e01d1ca7a$496fce60$dc4f6b20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHKX8vhiluIuEjDLHw/pgEUJ1SG/wHqgDMoAnvLMY8BLcydi5/TkvRQ Content-Language: en-us Archived-At: Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt 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: Sun, 19 Jun 2016 22:31:16 -0000 Ok, there are two possible reasons for that statement. The first is you = just think that the title that I like is a worse title. The second is = following on from Carsten's mail which says that we need to expand = acronyms. If it is the latter, then the correct title of the document = is: COSE: Concise Binary Object Representation (CBOR) Object Signing and = Encryption. Or Concise Binary Object Representation (CBOR) Object Signing and = Encryption (COSE) Of those two titles, I prefer the second and it does not try to be prose = but is just the expansion. Jim > -----Original Message----- > From: Justin Richer [mailto:jricher@mit.edu] > Sent: Sunday, June 19, 2016 1:23 PM > To: Kepeng Li ; Jim Schaad > ; cose@ietf.org > Subject: Re: [COSE] FW: New Version Notification for = draft-ietf-cose-msg-13.txt >=20 > I agree with Kepeng and others on the title: "COSE: CBOR Object = Signing and > Encryption". >=20 > -- Justin >=20 >=20 > On 6/18/2016 9:34 AM, Kepeng Li wrote: > > Just some questions for clarification. > > > > 1. About the document title, COSE: A Message Based Security Solution > > for CBOR, why don=E2=80=99t we use something like this: COSE: CBOR = Object > > Signing and Encyption specification? > > > > 2. Section 13, section title is just "keys=E2=80=9C, should we be = more specific? > > Maybe it is too genetic to say just keys. We have talked about keys = in > > several sections. We need to diffentiate this section with other > > places from the title. > > > > 3. Section 17, "implementation status=E2=80=9C, this is an = informative section. > > Should we move it to appendix? > > > > Kind Regards > > Kepeng > > (Individual) > > > > =E5=9C=A8 17/6/16 3:18 pm=EF=BC=8C "Jim Schaad" = =E5=86=99=E5=85=A5: > > > >> This draft responds to the vast majority of the last call comments > >> that have been received. Mail about outstanding issues was sent at > >> the time the pull requests were created but no responses have been = received. > >> > >> I believe that any remaining issues could be treated as IETF last > >> call comments or can be dealt with as the same time that AD = comments > >> are dealt with. With this in mind, I would request that the chairs > >> review the document for advancement. > >> > >> Jim > >> > >> > >>> -----Original Message----- > >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >>> Sent: Friday, June 17, 2016 12:10 AM > >>> To: Jim Schaad > >>> Subject: New Version Notification for draft-ietf-cose-msg-13.txt > >>> > >>> > >>> A new version of I-D, draft-ietf-cose-msg-13.txt has been > >>> successfully submitted by Jim Schaad and posted to the IETF > >>> repository. > >>> > >>> Name: draft-ietf-cose-msg > >>> Revision: 13 > >>> Title: COSE: A Message Based Security Solution for CBOR > >>> Document date: 2016-06-17 > >>> Group: cose > >>> Pages: 115 > >>> URL: > >>> https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-13.txt > >>> Status: = https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > >>> Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-13 > >>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-msg-13 > >>> > >>> Abstract: > >>> Concise Binary Object Representation (CBOR) is data format = designed > >>> for small code size and small message size. There is a need = for the > >>> ability to have the basic security services defined for this = data > >>> format. This document defines the CBOR Object Signing and = Encyption > >>> (COSE) specification. This specification describes how to = create and > >>> process signature, message authentication codes and encryption = using > >>> CBOR for serialization. This specifiction additionally = specifies how > >>> to representat cryptographic keys using CBOR. > >>> > >>> > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > >>> submission until the htmlized version and diff are available at > >>> tools.ietf.org. > >>> > >>> The IETF Secretariat > >> > >> _______________________________________________ > >> 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 From nobody Sun Jun 19 16:03:19 2016 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 4D29C12D110 for ; Sun, 19 Jun 2016 16:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 8DZmaUgD4jiz for ; Sun, 19 Jun 2016 16:03:16 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932FC12D630 for ; Sun, 19 Jun 2016 16:03:16 -0700 (PDT) Received: from mfilter37-d.gandi.net (mfilter37-d.gandi.net [217.70.178.168]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id DEC7BFB8A0; Mon, 20 Jun 2016 01:03:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter37-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter37-d.gandi.net (mfilter37-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id zBn-bxYBzKGr; Mon, 20 Jun 2016 01:03:13 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 9F36FFB88B; Mon, 20 Jun 2016 01:03:09 +0200 (CEST) Message-ID: <576724AB.1090509@tzi.org> Date: Mon, 20 Jun 2016 01:03:07 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Jim Schaad References: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> <012e01d1ca7a$496fce60$dc4f6b20$@augustcellars.com> In-Reply-To: <012e01d1ca7a$496fce60$dc4f6b20$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Kepeng Li' , 'Justin Richer' , cose@ietf.org Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt 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: Sun, 19 Jun 2016 23:03:18 -0000 Jim Schaad wrote: > Concise Binary Object Representation (CBOR) Object Signing and Encryption (COSE) That is pretty funny :-) The RFC editor has not insisted on expanding the term "JSON" in titles such as JSON Responses for the Registration Data Access Protocol (RDAP). I hope we can do the same for CBOR. But COSE is a new abbreviation to be introduced by this very RFC, so that indeed should be expanded. (If its expansion means something; e.g., SOAP famously doesn't any more.) Grüße, Carsten From nobody Sun Jun 19 17:39:10 2016 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 0E76112D786 for ; Sun, 19 Jun 2016 17:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 uNJzTSgDlmn2 for ; Sun, 19 Jun 2016 17:39:07 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5824A12D681 for ; Sun, 19 Jun 2016 17:39:07 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 8E0612CA0B; Sun, 19 Jun 2016 17:39:06 -0700 (PDT) From: "Jim Schaad" To: "'Carsten Bormann'" References: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> <012e01d1ca7a$496fce60$dc4f6b20$@augustcellars.com> <576724AB.1090509@tzi.org> In-Reply-To: <576724AB.1090509@tzi.org> Date: Sun, 19 Jun 2016 17:39:06 -0700 Message-ID: <013c01d1ca8c$26e77430$74b65c90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHKX8vhiluIuEjDLHw/pgEUJ1SG/wHqgDMoAnvLMY8BLcydiwJr5vzVAiSBgJifrzNr4A== Content-Language: en-us Archived-At: Cc: 'Kepeng Li' , 'Justin Richer' , cose@ietf.org Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt 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: Mon, 20 Jun 2016 00:39:09 -0000 I would argue that it does not really mean anything. The fact that = Object is basically repeated twice in the expansion is an artifact of = trying to get something pronounceable but no something that makes sense. = If we were going for something that made sense, I would argue that CSE = would be more reasonable as it does not duplicate the object of CBOR. = COSE was chosen as much to parallel with JOSE as anything else but those = specs are JWE and JWS not JOSE. =20 Maybe we should start from scratch and build a new acronym that makes = sense and stop using COSE. (By the way, I note that CBOR is not on = https://www.rfc-editor.org/materials/abbrev.expansion.txt so you might = want to ask the RFC Editor to add it.) Jim > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Sunday, June 19, 2016 4:03 PM > To: Jim Schaad > Cc: 'Justin Richer' ; 'Kepeng Li' = inc.com>; cose@ietf.org > Subject: Re: [COSE] FW: New Version Notification for = draft-ietf-cose-msg-13.txt >=20 > Jim Schaad wrote: > > Concise Binary Object Representation (CBOR) Object Signing and > > Encryption (COSE) >=20 > That is pretty funny :-) >=20 > The RFC editor has not insisted on expanding the term "JSON" in titles = such as >=20 > JSON Responses for the Registration Data Access Protocol (RDAP). >=20 > I hope we can do the same for CBOR. >=20 > But COSE is a new abbreviation to be introduced by this very RFC, so = that indeed > should be expanded. (If its expansion means something; e.g., SOAP = famously > doesn't any more.) >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jun 19 23:14:24 2016 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 0F4A312D763 for ; Sun, 19 Jun 2016 23:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 3-um8e7vMyBH for ; Sun, 19 Jun 2016 23:14:21 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78B712D760 for ; Sun, 19 Jun 2016 23:14:20 -0700 (PDT) Received: from mfilter10-d.gandi.net (mfilter10-d.gandi.net [217.70.178.139]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 9300D1720A4; Mon, 20 Jun 2016 08:14:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter10-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter10-d.gandi.net (mfilter10-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id rGyaAZjQEpoW; Mon, 20 Jun 2016 08:14:17 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 27CA917209F; Mon, 20 Jun 2016 08:14:10 +0200 (CEST) Message-ID: <576789AB.8070609@tzi.org> Date: Mon, 20 Jun 2016 08:14:03 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Jim Schaad References: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> <012e01d1ca7a$496fce60$dc4f6b20$@augustcellars.com> <576724AB.1090509@tzi.org> <013c01d1ca8c$26e77430$74b65c90$@augustcellars.com> In-Reply-To: <013c01d1ca8c$26e77430$74b65c90$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Kepeng Li' , 'Justin Richer' , cose@ietf.org Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt 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: Mon, 20 Jun 2016 06:14:23 -0000 Jim Schaad wrote: > I would argue that it does not really mean anything. The fact that Object is basically repeated twice in the expansion is an artifact of trying to get something pronounceable but no something that makes sense. If we were going for something that made sense, I would argue that CSE would be more reasonable as it does not duplicate the object of CBOR. COSE was chosen as much to parallel with JOSE as anything else but those specs are JWE and JWS not JOSE. CWS and CWE would not make that much sense *). (I also don't know why we'd need multiple initialisms for what is essentially a single format.) I'm actually very comfortable about the O (Object) in the name, as COSE can be used for what is widely called Object Security. > Maybe we should start from scratch and build a new acronym that makes sense and stop using COSE. It seems most people here are quite happy with the name. It also has been publicized a bit already. And the analogism with JOSE is quite useful. > (By the way, I note that CBOR is not on https://www.rfc-editor.org/materials/abbrev.expansion.txt so you might want to ask the RFC Editor to add it.) So far there has been no need to do this, as no other RFC (besides RFC 7049, which is defining the abbreviation) has had CBOR in the title yet. Indeed, this RFC would be the occasion where we make this request. Grüße, Carsten *) Yeah, we now could be arguing about CWT, but that is another WG's job :-) From nobody Mon Jun 20 04:47:48 2016 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 9875112D563 for ; Mon, 20 Jun 2016 04:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 pF-0cdwfl_kB for ; Mon, 20 Jun 2016 04:47:44 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 895EB12B03F for ; Mon, 20 Jun 2016 04:47:43 -0700 (PDT) X-AuditID: 1209190e-b73ff70000003482-85-5767d7de144e 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 93.54.13442.ED7D7675; Mon, 20 Jun 2016 07:47:42 -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 u5KBlf45005999; Mon, 20 Jun 2016 07:47:41 -0400 Received: from [192.168.6.175] (ip-64-134-241-184.public.wayport.net [64.134.241.184]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u5KBlcq3000750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Jun 2016 07:47:39 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: <012e01d1ca7a$496fce60$dc4f6b20$@augustcellars.com> Date: Mon, 20 Jun 2016 07:47:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3C88BB59-B9A0-4E57-B109-785B1A9AFBBD@mit.edu> References: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> <012e01d1ca7a$496fce60$dc4f6b20$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nrnvvenq4wdfl6hbTtk5ltVg9/Tub xeX5RQ7MHhPffmTx2DhnOpvHkiU/mQKYo7hsUlJzMstSi/TtErgyfu1dyVhwSadi72HOBsYN Kl2MnBwSAiYSnTdesXYxcnEICbQxSbQvfMcC4WxklPg06zWUc5lJYsmJrWwgLcwC6hJ/5l1i BrF5BfQkNq1/ywRiCwv4S1w7sRAsziagKjF9TQtYnFPAQeL4ozawXhag+MGbc1kh5jhI3Hg0 kx3C1pZYtvA11EwriU/Le5ghFrcwSVx9+BasSARo8dbVN5kg7paVeHJyEcsERoFZSG6aheSm WUjmLmBkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRrrJebWaKXmlK6iREUvJySfDsYJzV4H2IU 4GBU4uG1OJsWLsSaWFZcmXuIUZKDSUmU16Y4PVyILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK/1 VaAcb0piZVVqUT5MSpqDRUmcl5GBgUFIID2xJDU7NbUgtQgmK8PBoSTBqwiMUiHBotT01Iq0 zJwShDQTByfIcB6g4fIgNbzFBYm5xZnpEPlTjIpS4rxzrwElBEASGaV5cL2g5OLQ9nHHK0Zx oFeEeVNBqniAiQmu+xXQYCagwcv6wQaXJCKkpBoYDadF+goUP52XN7dI+5aChVhlAb/tKvEf f8LnTpCPmvnPdvJbNt+oKVrlpcrn9WzvFD+KT7bfv7LglPPcuGOfBWv2Gxhe2pcbF85yYgmP Qp5/ygeZ0vS79x4f+cj2MarDdLrEZTbhy1FHrdczM6c9mhK2r3r+kb38KVEPMxfdtHpu2WN9 SfKSEktxRqKhFnNRcSIAn8q/TgkDAAA= Archived-At: Cc: Kepeng Li , cose Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt 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: Mon, 20 Jun 2016 11:47:46 -0000 It=E2=80=99s both, really. I don=E2=80=99t think the other title is = descriptive. We need to expand COSE, since we define it, but we don=E2=80=99= t need to expand CBOR, since that=E2=80=99s already defined by another = RFC. You don=E2=80=99t see other RFC=E2=80=99s expanding HTTP except for = the HTTP RFC=E2=80=99s, for example, so your argument below is a bit = extreme in making the alternative look absurd. The title should be: CBOR Object Signing and Encryption (COSE) or: COSE: CBOR Object Signing and Encryption Either style is fine with me.=20 You seem to be the only one arguing for the other title, which tells me = that there=E2=80=99s not consensus to change the name away from COSE as = stated on the working group description page, charter, and everywhere = else to date: https://datatracker.ietf.org/wg/cose/ As such, please use one of the two titles above. Thank you, =E2=80=94 Justin > On Jun 19, 2016, at 6:31 PM, Jim Schaad = wrote: >=20 > Ok, there are two possible reasons for that statement. The first is = you just think that the title that I like is a worse title. The second = is following on from Carsten's mail which says that we need to expand = acronyms. If it is the latter, then the correct title of the document = is: >=20 > COSE: Concise Binary Object Representation (CBOR) Object Signing and = Encryption. >=20 > Or >=20 > Concise Binary Object Representation (CBOR) Object Signing and = Encryption (COSE) >=20 > Of those two titles, I prefer the second and it does not try to be = prose but is just the expansion. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: Justin Richer [mailto:jricher@mit.edu] >> Sent: Sunday, June 19, 2016 1:23 PM >> To: Kepeng Li ; Jim Schaad >> ; cose@ietf.org >> Subject: Re: [COSE] FW: New Version Notification for = draft-ietf-cose-msg-13.txt >>=20 >> I agree with Kepeng and others on the title: "COSE: CBOR Object = Signing and >> Encryption". >>=20 >> -- Justin >>=20 >>=20 >> On 6/18/2016 9:34 AM, Kepeng Li wrote: >>> Just some questions for clarification. >>>=20 >>> 1. About the document title, COSE: A Message Based Security Solution >>> for CBOR, why don=E2=80=99t we use something like this: COSE: CBOR = Object >>> Signing and Encyption specification? >>>=20 >>> 2. Section 13, section title is just "keys=E2=80=9C, should we be = more specific? >>> Maybe it is too genetic to say just keys. We have talked about keys = in >>> several sections. We need to diffentiate this section with other >>> places from the title. >>>=20 >>> 3. Section 17, "implementation status=E2=80=9C, this is an = informative section. >>> Should we move it to appendix? >>>=20 >>> Kind Regards >>> Kepeng >>> (Individual) >>>=20 >>> =E5=9C=A8 17/6/16 3:18 pm=EF=BC=8C "Jim Schaad" = =E5=86=99=E5=85=A5: >>>=20 >>>> This draft responds to the vast majority of the last call comments >>>> that have been received. Mail about outstanding issues was sent at >>>> the time the pull requests were created but no responses have been = received. >>>>=20 >>>> I believe that any remaining issues could be treated as IETF last >>>> call comments or can be dealt with as the same time that AD = comments >>>> are dealt with. With this in mind, I would request that the chairs >>>> review the document for advancement. >>>>=20 >>>> Jim >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>> Sent: Friday, June 17, 2016 12:10 AM >>>>> To: Jim Schaad >>>>> Subject: New Version Notification for draft-ietf-cose-msg-13.txt >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-ietf-cose-msg-13.txt has been >>>>> successfully submitted by Jim Schaad and posted to the IETF >>>>> repository. >>>>>=20 >>>>> Name: draft-ietf-cose-msg >>>>> Revision: 13 >>>>> Title: COSE: A Message Based Security Solution for CBOR >>>>> Document date: 2016-06-17 >>>>> Group: cose >>>>> Pages: 115 >>>>> URL: >>>>> https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-13.txt >>>>> Status: = https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >>>>> Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-13 >>>>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-msg-13 >>>>>=20 >>>>> Abstract: >>>>> Concise Binary Object Representation (CBOR) is data format = designed >>>>> for small code size and small message size. There is a need = for the >>>>> ability to have the basic security services defined for this = data >>>>> format. This document defines the CBOR Object Signing and = Encyption >>>>> (COSE) specification. This specification describes how to = create and >>>>> process signature, message authentication codes and encryption = using >>>>> CBOR for serialization. This specifiction additionally = specifies how >>>>> to representat cryptographic keys using CBOR. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>>=20 >>>>> The IETF Secretariat >>>>=20 >>>> _______________________________________________ >>>> COSE mailing list >>>> COSE@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cose >>>=20 >>> _______________________________________________ >>> COSE mailing list >>> COSE@ietf.org >>> https://www.ietf.org/mailman/listinfo/cose >=20 >=20 From nobody Mon Jun 20 05:53:02 2016 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 40CB912D09D for ; Mon, 20 Jun 2016 05:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics-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 Cc9EjYL6IsLX for ; Mon, 20 Jun 2016 05:52:59 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 BC80312B05C for ; Mon, 20 Jun 2016 05:52:58 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id q132so36965127lfe.3 for ; Mon, 20 Jun 2016 05:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=zNmIDLqGUYqLatlCg/1Z8KL8GwVxJKlKM7LHEWVgJGs=; b=ksY7slE+lnKdZLgSIm1iNvmMqYAtqKJiR6dTHmQsaUq6lzgZ5k8nRM6iqW9lVuy8U6 sdgTpHB3QGWZHh/oCnLr+XmrS3h1JYLiQFDho5m6DhJCZDCTjm6LDpf1tn/4y7DtofJs yDky0TF64hY6Z2ii3q2rJWhIT95C1TaXfUYxqs41crczZxsHDQMBrIFyfeqto+4rGvdG QJI6Go8aKmkTCWvUtmpblGyvQYtgRSoFGJFmAParFbAJTJ9+QPN3wkE2WuOVe17LRK0K 1oiFd13aZH6DTwwtLpT7Kccuaa2b9i1ntoJhmV86JCyx2k8cvBuiXUCiz3nbj7TiHUjL NMnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=zNmIDLqGUYqLatlCg/1Z8KL8GwVxJKlKM7LHEWVgJGs=; b=dRWq7q9viMWKcfmE9guS0rmDOdM4c+fC9Ots/a+xBU9aibxQIpRu6mvxbXjfOcbygz AYqqdYF1VV1pp0NCgD5JBAOrKuM+ZhMEByNmms/P73Uu3MWXxoxBbSS+ECNh741YR1Ny CF3OwwHylGHXh64RqwlKlgmQzj+w8Yg/bG97KgxotZBlwyPcdGQlXdGwi0KxWX/863lL VL0jwLSP8cfILmdruCpn1+1IwxSmInAnJnq4u6vkV5s5HEMAR32n0yyYgzGhjfUVO8L7 z8WE6TP8qdCcyaMuBn+xcKhlLX/W/MVry5OfCOKyg7YiPAoGccTHSfK8GNEZaatnrPLl yaTA== X-Gm-Message-State: ALyK8tILJqD8BfMlfoGJoxZ6RqMNn5Ya+P30uYYRPqIj+ksTYXaI/lOUEqRfDmLPnoM3sI/C X-Received: by 10.25.162.6 with SMTP id l6mr3317686lfe.137.1466427171751; Mon, 20 Jun 2016 05:52:51 -0700 (PDT) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id kz1sm6273810lbc.4.2016.06.20.05.52.50 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2016 05:52:51 -0700 (PDT) To: cose@ietf.org References: <20160617071014.19121.43331.idtracker@ietfa.amsl.com> <01eb01d1c868$689e8bf0$39dba3d0$@augustcellars.com> <012e01d1ca7a$496fce60$dc4f6b20$@augustcellars.com> <3C88BB59-B9A0-4E57-B109-785B1A9AFBBD@mit.edu> From: Ludwig Seitz Message-ID: <5767E722.1090609@sics.se> Date: Mon, 20 Jun 2016 14:52:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <3C88BB59-B9A0-4E57-B109-785B1A9AFBBD@mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080405030408070802030501" Archived-At: Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-13.txt 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: Mon, 20 Jun 2016 12:53:01 -0000 This is a cryptographically signed message in MIME format. --------------ms080405030408070802030501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2016-06-20 13:47, Justin Richer wrote: > It=E2=80=99s both, really. I don=E2=80=99t think the other title is des= criptive. We > need to expand COSE, since we define it, but we don=E2=80=99t need to e= xpand > CBOR, since that=E2=80=99s already defined by another RFC. You don=E2=80= =99t see > other RFC=E2=80=99s expanding HTTP except for the HTTP RFC=E2=80=99s, f= or example, so > your argument below is a bit extreme in making the alternative look > absurd. The title should be: > > CBOR Object Signing and Encryption (COSE) > I have a slight preference for this one, since it follows the patterns=20 of the JOSE specs: "JSON Web * (JW*)" and as Justin said in his introductory presentation at IETF 93: "What would JOSE do?" /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=C3=A4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms080405030408070802030501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK /swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji /GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0 +jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84 MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6 V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA 0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf 1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/ tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH 2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9 VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp /2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjA2MjAxMjUyNTBaMC8GCSqGSIb3DQEJBDEiBCAnoKx3oFs8 kH0nHgfcDfzv/d1uob4iioEjk7iah8+HmTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQBmeX/KfH9WRG519eb0JQex mPUNMkdVKPk114jLe8kWtwOfvA7ipyq/9nRG5ZCojj5Vpw1jK2k4GVK9QM8wHx2JsgEueq/a GwpTKO0Wn67p7ThVp2tTBpTyUIJmDIVWb6GY8icOZUhKpbmbAXg7GgQL7c99G2k8m+efl2XP p+Ntw8Ek2r882aT5mhGa8D2ecqlRHXq+5h8RBFuOtNKrLEbYIO088i6JC+an+E0y+5UdKvHO qrvp1vA5xZBXbQ6vdqqoq075awbWyLHgYPrOM4MOuv/ZhpVIQi83K2tCp4lqteWd0gs63pKu x5ECNtaZJiiVy1b+fWYhQ+XDxp+igWy2AAAAAAAA --------------ms080405030408070802030501-- From nobody Thu Jun 23 12:12:38 2016 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC6212D756; Thu, 23 Jun 2016 12:12:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160623191233.12564.31142.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2016 12:12:33 -0700 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-14.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 19:12:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption of the IETF. Title : CBOR Object Signing and Encryption (COSE) Author : Jim Schaad Filename : draft-ietf-cose-msg-14.txt Pages : 115 Date : 2016-06-23 Abstract: Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have the basic security services defined for this data format. This document defines the CBOR Object Signing and Encyption (COSE) specification. This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization. This specifiction additionally specifies how to representat cryptographic keys using CBOR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 24 09:10:13 2016 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2586412DD59; Fri, 24 Jun 2016 09:01:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160102.10933.35354.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:01:02 -0700 Archived-At: Cc: Kathleen.Moriarty.ietf@gmail.com, cose@ietf.org Subject: [COSE] cose - Requested session has been scheduled for IETF 96 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:01:02 -0000 Dear Kepeng Li, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. cose Session 1 (1:00:00) Thursday, Morning Session I 1000-1230 Room Name: Charlottenburg I size: 80 --------------------------------------------- Special Note: 11:30-12:30 Request Information: --------------------------------------------------------- Working Group Name: CBOR Object Signing and Encryption Area Name: Security Area Session Requester: Kepeng Li Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: ace core oauth abfab sacm radext dime tls Second Priority: dane httpauth kitten saag Third Priority: httpbis sidr Special Requests: ---------------------------------------------------------