From nobody Mon Jan 4 11:26:35 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927301A909F for ; Mon, 4 Jan 2016 11:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[BAYES_60=1.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 UiFfxZoNuSBV for ; Mon, 4 Jan 2016 11:26:33 -0800 (PST) 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 9BB401A90A5 for ; Mon, 4 Jan 2016 11:26:33 -0800 (PST) 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: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id C2BD538EFF for ; Mon, 4 Jan 2016 11:26:32 -0800 (PST) From: "Jim Schaad" To: Date: Mon, 4 Jan 2016 11:23:54 -0800 Message-ID: <0c7a01d14725$738827c0$5a987740$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdFHJABVoEwGvFdkQtW9BzrfPd4xnQ== Content-Language: en-us Archived-At: Subject: [COSE] Issue - Restore 'use' COS key parameter description X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 19:26:34 -0000 This starts a fast series of emails trying to get the current set of issues resolved. JOSE has a historical key parameter of 'use' which was defined long before the 'key_ops' parameter was defined at the request of the W3C WebCrypto group. These parameters do the same basic thing - they say what operations a key can be used for. I am not clear what level they are being used in the wild, but I expect that 'use' is far more commonly used if only because it was defined several years before 'key_ops' was used. Part of the discussion at the time of JOSE was to make the 'use' parameter be either a single value or an array of values. This was resisted as being too complicated for programmers to deal with. Instead they need to deal with the possibility that a key contains both the 'use' and 'key_ops' parameter and make sure that they are consistent with each other. The version of the message document -09 contains text which harmonizes it with the W3C work in terms of what is needed for 'key_ops' to be set correctly. I would like to have only single structure that deals with the permissions assigned to a key. This can be done by not putting the 'use' parameter back into the document. If there is a strong desire to have something that maps closer, then it would be reasonable to allow for 'key_ops' to have either a single value or an array of values. This would mean that there is a basic equivalence to 'use' and 'key_ops' for a single value case as long as one believes that 'use' was really only designed to talk about public key operations and not private key operations. I would like to close this issue by the end of the week. Jim From nobody Mon Jan 4 11:31:42 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052B41A90A0 for ; Mon, 4 Jan 2016 11:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 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 UlmSw5GBHRrs for ; Mon, 4 Jan 2016 11:31:38 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4EA1A909F for ; Mon, 4 Jan 2016 11:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4S4NBREASnr49Fbs95aTu3APhqczZSGgIWjGq7SqnsQ=; b=itm80fhTViqI26allNW87BGxd7LnQmQIzLAbaIBtMLMYZ1AXR4wYEVXntbnhBlkRZJYUHRXkvg6UQ78SAu69V4qCQhV6U7cWeBg6KXJ/aSvu2oSEAZUcp+0BEW+1tOb5hSt450ZV6id2FMrGozKWu5JMxvKs0oXNDU32KT+V564= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 4 Jan 2016 19:31:34 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0361.006; Mon, 4 Jan 2016 19:31:34 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] Issue - Restore 'use' COS key parameter description Thread-Index: AdFHJABVoEwGvFdkQtW9BzrfPd4xnQAAoSof Date: Mon, 4 Jan 2016 19:31:33 +0000 Message-ID: References: <0c7a01d14725$738827c0$5a987740$@augustcellars.com> In-Reply-To: <0c7a01d14725$738827c0$5a987740$@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: [64.134.138.1] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:nawOSYu3H81UpAEd0hbxyB4rv8Xj0MCEvdZWNmhOgYm8QsaQvBe+td3mAitRweENgjrwf/QAq7oIEwUYb+WR7ZISkmbWZd73BCMFYSpIheTqX+0joNV0sLN5Q0px1lz5vrKQqihEmvo5/YqgAvztmg==; 24:hsf2FbRi1gz7CkccUeHbEHIHRXTBC18v2daNDtwq+o59f0x2kJIpTq/6Z+xBDYqyp4BkGw9sNRY3DDww0niQ5/EIy8kmk7cJiW4XwMxdf38= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 08118EFC2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(164054003)(37984002)(377454003)(189002)(19580395003)(5003600100002)(50986999)(86362001)(586003)(81156007)(99286002)(189998001)(19580405001)(19617315012)(101416001)(87936001)(10400500002)(5005710100001)(105586002)(2900100001)(86612001)(54356999)(5008740100001)(66066001)(8990500004)(5004730100002)(16236675004)(2950100001)(40100003)(122556002)(15975445007)(92566002)(74316001)(1096002)(5002640100001)(76176999)(10290500002)(2501003)(5001960100002)(33656002)(97736004)(10090500001)(106356001)(1220700001)(5001770100001)(77096005)(107886002)(76576001)(6116002)(102836003)(19625215002)(3846002)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44205E107AA4D7C67C2E92BF5F20BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2016 19:31:33.7935 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [COSE] Issue - Restore 'use' COS key parameter description X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 19:31:41 -0000 --_000_BY2PR03MB44205E107AA4D7C67C2E92BF5F20BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable I will be on vacation until Wednesday. Please take no action to close any i= ssues I've opened until I've had a chance to review the proposed resolution= s later in the week. Thanks, -- Mike ________________________________ From: Jim Schaad Sent: =FD1/=FD4/=FD2016 11:26 AM To: cose@ietf.org Subject: [COSE] Issue - Restore 'use' COS key parameter description This starts a fast series of emails trying to get the current set of issues resolved. JOSE has a historical key parameter of 'use' which was defined long before the 'key_ops' parameter was defined at the request of the W3C WebCrypto group. These parameters do the same basic thing - they say what operations a key can be used for. I am not clear what level they are being used in th= e wild, but I expect that 'use' is far more commonly used if only because it was defined several years before 'key_ops' was used. Part of the discussion at the time of JOSE was to make the 'use' parameter be either a single value or an array of values. This was resisted as being too complicated for programmers to deal with. Instead they need to deal with the possibility that a key contains both the 'use' and 'key_ops' parameter and make sure that they are consistent with each other. The version of the message document -09 contains text which harmonizes it with the W3C work in terms of what is needed for 'key_ops' to be set correctly. I would like to have only single structure that deals with the permissions assigned to a key. This can be done by not putting the 'use' parameter bac= k into the document. If there is a strong desire to have something that maps closer, then it would be reasonable to allow for 'key_ops' to have either a single value or an array of values. This would mean that there is a basic equivalence to 'use' and 'key_ops' for a single value case as long as one believes that 'use' was really only designed to talk about public key operations and not private key operations. I would like to close this issue by the end of the week. Jim _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose --_000_BY2PR03MB44205E107AA4D7C67C2E92BF5F20BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
I will be on = vacation until Wednesday. Please take no action to close any issues I've op= ened until I've had a chance to review the proposed resolutions later in th= e week.

Thanks,
-- Mike
From: Jim Schaad
Sent: =FD1/= =FD4/=FD2016 11:26 AM
To: cose@ietf.org
Subject: [COSE= ] Issue - Restore 'use' COS key parameter description

This starts a fast series of emails trying to get = the current set of issues
resolved.

JOSE has a historical key parameter of 'use' which was defined long before<= br> the 'key_ops' parameter was defined at the request of the W3C WebCrypto
group.  These parameters do the same basic thing - they say what opera= tions
a key can be used for.  I am not clear what level they are being used = in the
wild, but I expect that 'use' is far more commonly used if only because it<= br> was defined several years before 'key_ops' was used.

Part of the discussion at the time of JOSE was to make the 'use' parameter<= br> be either a single value or an array of values.  This was resisted as = being
too complicated for programmers to deal with.  Instead they need to de= al
with the possibility that a key contains both the 'use' and 'key_ops'
parameter and make sure that they are consistent with each other.

The version of the message document -09 contains text which harmonizes it with the W3C work in terms of what is needed for 'key_ops' to be set
correctly.

I would like to have only  single structure that deals with the permis= sions
assigned to a key.  This can be done by not putting the 'use' paramete= r back
into the document.  If there is a strong desire to have something that= maps
closer, then it would be reasonable to allow for 'key_ops' to have either a=
single value or an array of values.  This would mean that there is a b= asic
equivalence to 'use' and 'key_ops' for a single value case as long as one believes that 'use' was really only designed to talk about public key
operations and not private key operations.

I would like to close this issue by the end of the week.

Jim


_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org= /mailman/listinfo/cose
 --_000_BY2PR03MB44205E107AA4D7C67C2E92BF5F20BY2PR03MB442namprd_-- From nobody Mon Jan 4 13:31:43 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A661AC3C3; Mon, 4 Jan 2016 13:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 kd9WCaxRdrSd; Mon, 4 Jan 2016 13:31:26 -0800 (PST) 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 9C8EA1AC3B9; Mon, 4 Jan 2016 13:31:20 -0800 (PST) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id F21242CA1D; Mon, 4 Jan 2016 13:31:19 -0800 (PST) From: "Jim Schaad" To: Date: Mon, 4 Jan 2016 13:28:34 -0800 Message-ID: <0c9901d14736$e2353940$a69fabc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdFHNZjhDG9OzhqoSgyS7pmJRsqwXw== Content-Language: en-us Archived-At: Cc: Ace@ietf.org Subject: [COSE] Should we support padding for Enveloped/Encrypted Messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:31:30 -0000 Padding of content is useful for dealing with traffic analysis attacks. This can be seen as becoming important as it is now part of the basic framework of TLS 1.3. One possible simple analysis that can be performed against sensors is looking for thresholds in reported values. Just looking at the message length, one can tell the difference between '9.0' and '10.0' unless the first item is padded out to the same length. For example using either '09.0' or ' 9.0'. We currently do not have any facility to do a generic padding and it is not clear that we should provide one. The benefit is that it would allow for the ability to reduce the set of traffic analysis attacks. The down side is that we probably need to have some type of length field added to encrypted content for all messages. This means that we potentially have a single byte (or more depending on how it is done) to all messages increasing the length. It is also not clear yet how much the IoT world cares about doing the type of protection in the near term. (It is possible that in time they may start caring.) One possible answer is to add the padding to the end of the current message ala the PKCS#7 padding. There would be N bytes appended to the end of the message, each containing the value of N. The default would be to append a single byte with the value of '1'. The use of padding would be described as being application specific rather than being generic. However the single byte would always need to be paid even if there was not padding done. At this time my inclination is to treat this as a problem that the application should be solving and to simply address it as a security consideration in the COSE message draft. Any comments? I would like to resolve this by the end of this week. Jim From nobody Mon Jan 4 13:47:20 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68DF1AC3C3 for ; Mon, 4 Jan 2016 13:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8Tef7QxKCQPY for ; Mon, 4 Jan 2016 13:47:17 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180911A9174 for ; Mon, 4 Jan 2016 13:47:17 -0800 (PST) X-AuditID: 12074425-f793c6d000006975-bd-568ae863c58a Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id D3.23.26997.368EA865; Mon, 4 Jan 2016 16:47:15 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u04LlFRp018102 for ; Mon, 4 Jan 2016 16:47:15 -0500 Received: from [10.17.91.118] (229.90.158-98.q9.net [98.158.90.229]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u04Ll3ba022793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 4 Jan 2016 16:47:11 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_90EF01E4-3836-4E0C-A77A-F22DEE0188AF" Message-Id: Date: Mon, 4 Jan 2016 13:47:01 -0800 To: cose@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixCmqrZv8oivMYFG/vsW0rVNZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfbWDtaCPr6K05eWMTYwbuHpYuTkkBAwkbi+5BgbhC0mceHe eiCbi0NIYDGTxNrFF1hBEkICRxglFq72hEhcYZI4cOY5I0iCTUBVYv7KW0wgNrNAgkTPtQ1A NgeHsICkxKG3RiBhXgEriaVzvrOA2CwCKhIbn59nBCkRERCUuNtpDlGiJ/Hq1mVWiBtkJXb/ fsQ0gZF3FpKhs5CUQcS1JZYtfM0MYWtK7O9ezoIpriHR+W0i6wJGtlWMsim5Vbq5iZk5xanJ usXJiXl5qUW6Fnq5mSV6qSmlmxhBAcnuorqDccIhpUOMAhyMSjy8Hl87w4RYE8uKK3MPMUpy MCmJ8h661hUmxJeUn1KZkVicEV9UmpNafIhRgoNZSYTX6j5QjjclsbIqtSgfJiXNwaIkzjv3 i2+YkEB6YklqdmpqQWoRTFaGg0NJgrfzOVCjYFFqempFWmZOCUKaiYMTZDgP0PA4kBre4oLE 3OLMdIj8KUZFKXFeW5CEAEgiozQPrheUMJLmRT19xSgO9Iow7ymQKh5gsoHrfgU0mAlo8JuK dpDBJYkIKakGxiVvHR/+8183S2J/ybaHp5NM9n3/eexN5JXqaxqvhXmY2vqCIwpPSAS2753t rBS/ifmQhPz9IJ+tB35VTgiV//DeXS7DYet8i2xfi73trq3fEvUPn1UtfWY7u+p8ac7q9YbP NfivXc+VSF/gVRF0p2aXfXyEeOuKpOntW932B3ZK1QQ/vX56hhJLcUaioRZzUXEiAMSguffz AgAA Archived-At: Subject: [COSE] Issue Completion X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:47:19 -0000 --Apple-Mail=_90EF01E4-3836-4E0C-A77A-F22DEE0188AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Our editor has tagged a number of issues as =E2=80=9CComplete=E2=80=9D.=20= https://github.com/cose-wg/cose-issues/labels/Complete = Please review this list to see if the issues enumerated here have been = adequately addressed in the latest drafts. Unless there is significant = debate on the resolution, the chairs will close these issues in one = week, on Monday, January 11. Thank you, =E2=80=94 Justin (your COSE chair)= --Apple-Mail=_90EF01E4-3836-4E0C-A77A-F22DEE0188AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Our editor has tagged a number of issues as = =E2=80=9CComplete=E2=80=9D. 

https://github.com/cose-wg/cose-issues/labels/Complete

Please review this = list to see if the issues enumerated here have been adequately addressed = in the latest drafts. Unless there is significant debate on the = resolution, the chairs will close these issues in one week, on Monday, = January 11.

Thank you,
 =E2=80=94 Justin (your = COSE chair)
= --Apple-Mail=_90EF01E4-3836-4E0C-A77A-F22DEE0188AF-- From nobody Mon Jan 4 14:08:39 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DC41AC40F; Mon, 4 Jan 2016 14:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7e6W-QI2eguS; Mon, 4 Jan 2016 14:08:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6A61AC408; Mon, 4 Jan 2016 14:08:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19755BE53; Mon, 4 Jan 2016 22:08:33 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl_A2bw86q9D; Mon, 4 Jan 2016 22:08:31 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.23.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 00E2EBE4D; Mon, 4 Jan 2016 22:08:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1451945311; bh=9BNp7ZA4d/GBoBlUEAFPvTzirHI4s56X1rtZrPm3TLY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gPuQARudDs0Ep3+vhT1atZ6QSPtXP6U0o2jEK0+dwU3vyduEIrA15vdjnXybaXuOx KGfVnk/8uFrp2l01+vpN93DX2ulYnd0ZfMdqJySZ8N6MzC/iTSVvjFkPrS5XeoCc6q /CxmahsH8mR2dhBiy6ktYk5uMuzxX5D0511kqxOE= To: Jim Schaad , cose@ietf.org References: <0c9901d14736$e2353940$a69fabc0$@augustcellars.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <568AED5E.7000408@cs.tcd.ie> Date: Mon, 4 Jan 2016 22:08:30 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <0c9901d14736$e2353940$a69fabc0$@augustcellars.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Ace@ietf.org Subject: Re: [COSE] [Ace] Should we support padding for Enveloped/Encrypted Messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 22:08:36 -0000 I would argue to try define a padding mechanism here. As you note, it may be important later and there are some real issues when dealing with constrained use-cases. In fact, in the limit one might want to define a padding-only form for COSE to handle the case where the existence of any traffic defeats any confidentiality protection. (E.g. sensor that fires a packet when temp==20C.) I know that that'd not often be useful but I think there will be times when it will. The argument that applications can best do this is not a bad one, but can be countered. If a node has a common crypto library that ensures that padding can be done consistently across multiple applications, which could be harder if not defined at this layer. (And even more likely, application developers don't care or don't bother or don't know how to do this well.) Cheers, S. PS: FWIW, I'd make the same argument for any protocol - I think we need to define basic padding mechanisms whenever we can now so that we or others can learn how to best use those later. On 04/01/16 21:28, Jim Schaad wrote: > Padding of content is useful for dealing with traffic analysis attacks. This > can be seen as becoming important as it is now part of the basic framework > of TLS 1.3. One possible simple analysis that can be performed against > sensors is looking for thresholds in reported values. Just looking at the > message length, one can tell the difference between '9.0' and '10.0' unless > the first item is padded out to the same length. For example using either > '09.0' or ' 9.0'. > > We currently do not have any facility to do a generic padding and it is not > clear that we should provide one. The benefit is that it would allow for the > ability to reduce the set of traffic analysis attacks. The down side is that > we probably need to have some type of length field added to encrypted > content for all messages. This means that we potentially have a single byte > (or more depending on how it is done) to all messages increasing the length. > It is also not clear yet how much the IoT world cares about doing the type > of protection in the near term. (It is possible that in time they may start > caring.) > > One possible answer is to add the padding to the end of the current message > ala the PKCS#7 padding. There would be N bytes appended to the end of the > message, each containing the value of N. The default would be to append a > single byte with the value of '1'. > > The use of padding would be described as being application specific rather > than being generic. However the single byte would always need to be paid > even if there was not padding done. > > At this time my inclination is to treat this as a problem that the > application should be solving and to simply address it as a security > consideration in the COSE message draft. > > Any comments? I would like to resolve this by the end of this week. > > Jim > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > From nobody Thu Jan 7 07:05:09 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5156D1A8BB1 for ; Thu, 7 Jan 2016 07:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_08=1.651, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 Tn3FCxKtT3QW for ; Thu, 7 Jan 2016 07:05:04 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext5.iad.github.net [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10301A8AE8 for ; Thu, 7 Jan 2016 07:05:03 -0800 (PST) Date: Thu, 07 Jan 2016 07:05:03 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1452179103; bh=BEjhuAYUyPAq85oYp0D835os7q9Q6cTOQ271Kw+i/tQ=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=wNRkMxxKWfajt54kDGjPO2LLMVz2VTRtxX7X72PeevN2FrS6y4bQSbBdkd/SZWh9k +Xm20MPYX5OmuxwXXAU/hU8Cynm99DtGUXaIrFg3gyfFf4E9SFNIhqLuxf7/KGDQv8 cmBgZLD2qQadvCSPTaOc1PDakIx/1K5tA1pSrL3w= From: Mike Jones To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_568e7e9f341c9_4a743fa435d3d2b879185"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: selfissued X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] "y > 0" should be "y >= 0" (#45) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 15:05:06 -0000 ----==_mimepart_568e7e9f341c9_4a743fa435d3d2b879185 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This looks good now. Thanks. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/45#issuecomment-169688185 ----==_mimepart_568e7e9f341c9_4a743fa435d3d2b879185 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

This looks good now. Thanks.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_568e7e9f341c9_4a743fa435d3d2b879185-- From nobody Thu Jan 7 18:23:33 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 2EED41AC422; Thu, 7 Jan 2016 18:23:32 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160108022332.32115.12761.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 18:23:32 -0800 Archived-At: Cc: Kathleen.Moriarty.ietf@gmail.com, cose-chairs@ietf.org, cose@ietf.org, kepeng.lkp@alibaba-inc.com Subject: [COSE] cose - New Meeting Session Request for IETF 95 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 02:23:32 -0000 A new 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.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: ace core oauth jose abfab sacm radext dime tls Second Priority: dane httpauth kitten dice saag Third Priority: httpbis sidr Special Requests: --------------------------------------------------------- From nobody Fri Jan 8 16:18:43 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF18B1B2CC9 for ; Fri, 8 Jan 2016 16:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 tMBugb0twjsS for ; Fri, 8 Jan 2016 16:18:40 -0800 (PST) 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 564031B2CC4 for ; Fri, 8 Jan 2016 16:18:40 -0800 (PST) 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: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 4ABF938EAA; Fri, 8 Jan 2016 16:18:39 -0800 (PST) From: "Jim Schaad" To: "Jones Mike" References: In-Reply-To: Date: Fri, 8 Jan 2016 16:16:02 -0800 Message-ID: <00b401d14a72$eccb5210$c661f630$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00B5_01D14A2F.DEAB1F50" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQHnVbEEf4RRBeXSolS/kzUPbuZGtgLLHPuunq/hEOA= Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Move_=E2=80=9Ccreation_time?= =?utf-8?b?4oCdIHZhbHVlIHRvIHRoZSBwYXlsb2FkICgjMTMp?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 00:18:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B5_01D14A2F.DEAB1F50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00B6_01D14A2F.DEAB1F50" ------=_NextPart_001_00B6_01D14A2F.DEAB1F50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Did you read the change in the text that was made at the same time? = It states that =E2=80=9CThe field is primarily intended to be to be used = for countersignatures, however it can additionally be used for replay = detection as well.=E2=80=9D It is not possible to put the time field in = the content for a countersignature as there is no customizable content = in that case. =20 =20 =20 From: Mike Jones [mailto:notifications@github.com]=20 Sent: Thursday, January 07, 2016 6:34 AM To: cose-wg/cose-issues Cc: Jim Schaad Subject: Re: [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D value to = the payload (#13) =20 Changing the name does not address the core issue that this field is = solely for use as defined by particular applications and has no = associated COSE processing rules. That says that it belongs in the CBOR = Web Token draft, which defines application payload fields, rather than = COSE messages spec. This field also duplicates the CWT "issued at" value at = https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#sect= ion-3.1.6. The "operation time" value should be deleted from this = specification to eliminate this unnecessary duplication - not just = renamed. =E2=80=94 Reply to this email directly or view it on GitHub = = . ------=_NextPart_001_00B6_01D14A2F.DEAB1F50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Did you read the change in the text that was made at the same = time?=C2=A0 =C2=A0=C2=A0It states that =E2=80=9CThe field is primarily = intended to be to be used for countersignatures, however it can = additionally be used for replay detection as well.=E2=80=9D=C2=A0 It is = not possible to put the time field in the content for a countersignature = as there is no customizable content in that = case.

 

 

 

From:<= /b> = Mike Jones [mailto:notifications@github.com]
Sent: Thursday, = January 07, 2016 6:34 AM
To: cose-wg/cose-issues = <cose-issues@noreply.github.com>
Cc: Jim Schaad = <ietf@augustcellars.com>
Subject: Re: [cose-issues] Move = =E2=80=9Ccreation time=E2=80=9D value to the payload = (#13)

 

Changing the name does not = address the core issue that this field is solely for use as defined by = particular applications and has no associated COSE processing rules. = That says that it belongs in the CBOR Web Token draft, which defines = application payload fields, rather than COSE messages = spec.

This field also duplicates the CWT "issued = at" value at https://tools.ietf.org/html/draft-wahlstroem-oauth-cbo= r-web-token-00#section-3.1.6. The "operation time" value = should be deleted from this specification to eliminate this unnecessary = duplication - not just renamed.

=E2=80=94
Reply to this email directly or view it on GitHub.3D"Image

------=_NextPart_001_00B6_01D14A2F.DEAB1F50-- ------=_NextPart_000_00B5_01D14A2F.DEAB1F50 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAABAAEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZq/9k= ------=_NextPart_000_00B5_01D14A2F.DEAB1F50-- From nobody Mon Jan 11 11:00:34 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C471A904D for ; Mon, 11 Jan 2016 11:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.042 X-Spam-Level: X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 F09S6711mqEa for ; Mon, 11 Jan 2016 11:00:31 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CACB11A904B for ; Mon, 11 Jan 2016 11:00:31 -0800 (PST) Date: Mon, 11 Jan 2016 11:00:30 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1452538830; bh=3jsWMTyuVgkdqeIb6nsIQNC59Px1iTHAByMaEpPIXUQ=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=n3PH7FUoTqxKUXglI8Lbvr8MjP5FRNmOCNxXZKUPNl3S/nej5ut1z3EKGPKul/j94 F+i10qkBAYZI8Hqquc5fiQpV9zs9Ll4cc/VtTwYayRQRYe1nNymC9GrYkS+Cjw8//I K3xIu7Lfi48ClrZQ5N1ff+3M4HD+yPbb7VFMgPpo= From: Mike Jones To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5693fbce3cb79_44a63fdbd9adf29c743982"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: selfissued X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] Add the statement: "COSE implementations only need to implement the features needed for the applications they are designed to support" (#50) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 19:00:33 -0000 ----==_mimepart_5693fbce3cb79_44a63fdbd9adf29c743982 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit OK - the Application Considerations Section now fulfills this ask - thanks. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/50#issuecomment-170653258 ----==_mimepart_5693fbce3cb79_44a63fdbd9adf29c743982 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

OK - the Application Considerations Section now fulfills this ask - thanks.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_5693fbce3cb79_44a63fdbd9adf29c743982-- From nobody Mon Jan 11 12:27:46 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78CC1A9103 for ; Mon, 11 Jan 2016 12:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 RitUo_Em_Kie for ; Mon, 11 Jan 2016 12:27:43 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0121.outbound.protection.outlook.com [65.55.169.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65FC1A9102 for ; Mon, 11 Jan 2016 12:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=z1SPNGO5PaaZjcd7DLUszH7V73Sr5IXgzVFADGNeVlw=; b=TjV+JqJLZlcdwBVWiiemwgn53f1AW4WSGtQBR0/gxLnI6uJ0vaaIGUeH65ieLG87sxjp4nibvKJAxVkduoS/I4XF8ZLUC2czCO0Ua+vQX2lK0rVC6vOqfUQCSAPuv19/cahw81tRkmUPHwPCKDvr8atHx6JQzzvVy9J4CUQ+fQE= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 11 Jan 2016 20:27:40 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0361.006; Mon, 11 Jan 2016 20:27:40 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: =?utf-8?B?W2Nvc2UtaXNzdWVzXSBNb3ZlIOKAnGNyZWF0aW9uIHRpbWXigJ0gdmFsdWUg?= =?utf-8?Q?to_the_payload_(#13)?= Thread-Index: AQHnVbEEf4RRBeXSolS/kzUPbuZGtgLLHPuunq/hEOCABHaKgA== Date: Mon, 11 Jan 2016 20:27:39 +0000 Message-ID: References: <00b401d14a72$eccb5210$c661f630$@augustcellars.com> In-Reply-To: <00b401d14a72$eccb5210$c661f630$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [12.130.116.69] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:hjJ3Jpytk/JC30zXhpDoUeN+SLjdr3BDkvVTuyr/Dd2MIryKUYBkYp6Fi4ZAgWYTjSCpQ2e9knnvTpDgMNxdyA752lY+261TUCDWhvUKQNvdGqZbQ3paKsjpzgoKiK676EWVqrH9qYRidMzq+srHMQ==; 24:jHGwwMmgXSruBogw9ioHkrMKtSYYeuPtXlK6507H8FDAIWwFMQBYfjENcmsyP8ti1lZTeWvfLCw9WuEbSNi/Cku2cQG9N/oMzO8bJ6Ehb48= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-ms-office365-filtering-correlation-id: 92b37478-de7d-4e85-a9db-08d31ac5a6f9 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(102615245)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(199003)(19617315012)(54356999)(40100003)(2900100001)(110136002)(99936001)(19625215002)(76576001)(74316001)(18206015028)(76176999)(17760045003)(16236675004)(5008740100001)(19580405001)(102836003)(99286002)(105586002)(86362001)(10090500001)(106356001)(87936001)(2950100001)(50986999)(189998001)(10400500002)(122556002)(97736004)(19580395003)(33656002)(86612001)(5005710100001)(101416001)(19609705001)(5004730100002)(81156007)(5003600100002)(5001960100002)(790700001)(11100500001)(6116002)(3846002)(92566002)(19300405004)(106116001)(5002640100001)(4326007)(8990500004)(77096005)(1096002)(2906002)(586003)(10290500002)(1220700001)(66066001)(15975445007)(19627595001)(7099028); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_BY2PR03MB442CB3C86CF332C79B29066F5C90BY2PR03MB442namprd_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2016 20:27:39.9756 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Move_=E2=80=9Ccreation_time?= =?utf-8?b?4oCdIHZhbHVlIHRvIHRoZSBwYXlsb2FkICgjMTMp?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 20:27:45 -0000 --_004_BY2PR03MB442CB3C86CF332C79B29066F5C90BY2PR03MB442namprd_ Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442CB3C86CF332C79B29066F5C90BY2PR03MB442namprd_" --_000_BY2PR03MB442CB3C86CF332C79B29066F5C90BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIG5vdy4gIFRoaXMgc3RpbGwgZmVlbHMgbGlrZSB1bm5lY2Vzc2FyeSBkdXBsaWNhdGlv biBvZiB0aGUgQ0JPUiBXZWIgVG9rZW4gKENXVCkg4oCcaWF04oCdIChpc3N1ZWQgYXQpPGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YWhsc3Ryb2VtLWFjZS1jYm9yLXdlYi10b2tl bi0wMCNzZWN0aW9uLTMuMS42PiBjbGFpbSB0byBtZSwgYnV0IEnigJltIGN1cmlvdXMgd2hhdCBv dGhlcnMgdGhpbmsuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEppbSBTY2hhYWQgW21haWx0bzppZXRm QGF1Z3VzdGNlbGxhcnMuY29tXQ0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDgsIDIwMTYgNDoxNiBQ TQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBjb3Nl QGlldGYub3JnDQpTdWJqZWN0OiBSRTogW2Nvc2UtaXNzdWVzXSBNb3ZlIOKAnGNyZWF0aW9uIHRp bWXigJ0gdmFsdWUgdG8gdGhlIHBheWxvYWQgKCMxMykNCg0KRGlkIHlvdSByZWFkIHRoZSBjaGFu Z2UgaW4gdGhlIHRleHQgdGhhdCB3YXMgbWFkZSBhdCB0aGUgc2FtZSB0aW1lPyAgICBJdCBzdGF0 ZXMgdGhhdCDigJxUaGUgZmllbGQgaXMgcHJpbWFyaWx5IGludGVuZGVkIHRvIGJlIHRvIGJlIHVz ZWQgZm9yIGNvdW50ZXJzaWduYXR1cmVzLCBob3dldmVyIGl0IGNhbiBhZGRpdGlvbmFsbHkgYmUg dXNlZCBmb3IgcmVwbGF5IGRldGVjdGlvbiBhcyB3ZWxsLuKAnSAgSXQgaXMgbm90IHBvc3NpYmxl IHRvIHB1dCB0aGUgdGltZSBmaWVsZCBpbiB0aGUgY29udGVudCBmb3IgYSBjb3VudGVyc2lnbmF0 dXJlIGFzIHRoZXJlIGlzIG5vIGN1c3RvbWl6YWJsZSBjb250ZW50IGluIHRoYXQgY2FzZS4NCg0K DQoNCkZyb206IE1pa2UgSm9uZXMgW21haWx0bzpub3RpZmljYXRpb25zQGdpdGh1Yi5jb21dDQpT ZW50OiBUaHVyc2RheSwgSmFudWFyeSAwNywgMjAxNiA2OjM0IEFNDQpUbzogY29zZS13Zy9jb3Nl LWlzc3VlcyA8Y29zZS1pc3N1ZXNAbm9yZXBseS5naXRodWIuY29tPG1haWx0bzpjb3NlLWlzc3Vl c0Bub3JlcGx5LmdpdGh1Yi5jb20+Pg0KQ2M6IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFy cy5jb208bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+Pg0KU3ViamVjdDogUmU6IFtjb3Nl LWlzc3Vlc10gTW92ZSDigJxjcmVhdGlvbiB0aW1l4oCdIHZhbHVlIHRvIHRoZSBwYXlsb2FkICgj MTMpDQoNCg0KQ2hhbmdpbmcgdGhlIG5hbWUgZG9lcyBub3QgYWRkcmVzcyB0aGUgY29yZSBpc3N1 ZSB0aGF0IHRoaXMgZmllbGQgaXMgc29sZWx5IGZvciB1c2UgYXMgZGVmaW5lZCBieSBwYXJ0aWN1 bGFyIGFwcGxpY2F0aW9ucyBhbmQgaGFzIG5vIGFzc29jaWF0ZWQgQ09TRSBwcm9jZXNzaW5nIHJ1 bGVzLiBUaGF0IHNheXMgdGhhdCBpdCBiZWxvbmdzIGluIHRoZSBDQk9SIFdlYiBUb2tlbiBkcmFm dCwgd2hpY2ggZGVmaW5lcyBhcHBsaWNhdGlvbiBwYXlsb2FkIGZpZWxkcywgcmF0aGVyIHRoYW4g Q09TRSBtZXNzYWdlcyBzcGVjLg0KDQpUaGlzIGZpZWxkIGFsc28gZHVwbGljYXRlcyB0aGUgQ1dU ICJpc3N1ZWQgYXQiIHZhbHVlIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13 YWhsc3Ryb2VtLW9hdXRoLWNib3Itd2ViLXRva2VuLTAwI3NlY3Rpb24tMy4xLjYuIFRoZSAib3Bl cmF0aW9uIHRpbWUiIHZhbHVlIHNob3VsZCBiZSBkZWxldGVkIGZyb20gdGhpcyBzcGVjaWZpY2F0 aW9uIHRvIGVsaW1pbmF0ZSB0aGlzIHVubmVjZXNzYXJ5IGR1cGxpY2F0aW9uIC0gbm90IGp1c3Qg cmVuYW1lZC4NCg0K4oCUDQpSZXBseSB0byB0aGlzIGVtYWlsIGRpcmVjdGx5IG9yIHZpZXcgaXQg b24gR2l0SHViPGh0dHBzOi8vZ2l0aHViLmNvbS9jb3NlLXdnL2Nvc2UtaXNzdWVzL2lzc3Vlcy8x MyNpc3N1ZWNvbW1lbnQtMTY5NjgwNDAyPi4NCg== --_000_BY2PR03MB442CB3C86CF332C79B29066F5C90BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw Ij5JIGhhdmUgbm93LiZuYnNwOyBUaGlzIHN0aWxsIGZlZWxzIGxpa2UgdW5uZWNlc3NhcnkgZHVw bGljYXRpb24gb2YgdGhlDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtd2FobHN0cm9lbS1hY2UtY2Jvci13ZWItdG9rZW4tMDAjc2VjdGlvbi0zLjEuNiI+DQpDQk9S IFdlYiBUb2tlbiAoQ1dUKSDigJxpYXTigJ0gKGlzc3VlZCBhdCk8L2E+IGNsYWltIHRvIG1lLCBi dXQgSeKAmW0gY3VyaW91cyB3aGF0IG90aGVycyB0aGluay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSmltIFNjaGFhZCBbbWFp bHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBK YW51YXJ5IDgsIDIwMTYgNDoxNiBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gY29zZUBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW2Nvc2UtaXNzdWVzXSBNb3ZlIOKAnGNyZWF0aW9u IHRpbWXigJ0gdmFsdWUgdG8gdGhlIHBheWxvYWQgKCMxMyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ RGlkIHlvdSByZWFkIHRoZSBjaGFuZ2UgaW4gdGhlIHRleHQgdGhhdCB3YXMgbWFkZSBhdCB0aGUg c2FtZSB0aW1lPyZuYnNwOyAmbmJzcDsmbmJzcDtJdCBzdGF0ZXMgdGhhdCDigJxUaGUgZmllbGQg aXMgcHJpbWFyaWx5IGludGVuZGVkIHRvIGJlIHRvIGJlIHVzZWQgZm9yIGNvdW50ZXJzaWduYXR1 cmVzLA0KIGhvd2V2ZXIgaXQgY2FuIGFkZGl0aW9uYWxseSBiZSB1c2VkIGZvciByZXBsYXkgZGV0 ZWN0aW9uIGFzIHdlbGwu4oCdJm5ic3A7IEl0IGlzIG5vdCBwb3NzaWJsZSB0byBwdXQgdGhlIHRp bWUgZmllbGQgaW4gdGhlIGNvbnRlbnQgZm9yIGEgY291bnRlcnNpZ25hdHVyZSBhcyB0aGVyZSBp cyBubyBjdXN0b21pemFibGUgY29udGVudCBpbiB0aGF0IGNhc2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNaWtlIEpvbmVzIFs8 YSBocmVmPSJtYWlsdG86bm90aWZpY2F0aW9uc0BnaXRodWIuY29tIj5tYWlsdG86bm90aWZpY2F0 aW9uc0BnaXRodWIuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFy eSAwNywgMjAxNiA2OjM0IEFNPGJyPg0KPGI+VG86PC9iPiBjb3NlLXdnL2Nvc2UtaXNzdWVzICZs dDs8YSBocmVmPSJtYWlsdG86Y29zZS1pc3N1ZXNAbm9yZXBseS5naXRodWIuY29tIj5jb3NlLWlz c3Vlc0Bub3JlcGx5LmdpdGh1Yi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSmltIFNjaGFh ZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iPmlldGZAYXVndXN0 Y2VsbGFycy5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2Nvc2UtaXNzdWVz XSBNb3ZlIOKAnGNyZWF0aW9uIHRpbWXigJ0gdmFsdWUgdG8gdGhlIHBheWxvYWQgKCMxMyk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5DaGFuZ2luZyB0aGUgbmFtZSBkb2VzIG5vdCBhZGRy ZXNzIHRoZSBjb3JlIGlzc3VlIHRoYXQgdGhpcyBmaWVsZCBpcyBzb2xlbHkgZm9yIHVzZSBhcyBk ZWZpbmVkIGJ5IHBhcnRpY3VsYXIgYXBwbGljYXRpb25zIGFuZCBoYXMgbm8gYXNzb2NpYXRlZCBD T1NFIHByb2Nlc3NpbmcgcnVsZXMuIFRoYXQgc2F5cyB0aGF0IGl0IGJlbG9uZ3MgaW4gdGhlIENC T1IgV2ViIFRva2VuIGRyYWZ0LCB3aGljaCBkZWZpbmVzIGFwcGxpY2F0aW9uIHBheWxvYWQNCiBm aWVsZHMsIHJhdGhlciB0aGFuIENPU0UgbWVzc2FnZXMgc3BlYy48bzpwPjwvbzpwPjwvcD4NCjxw PlRoaXMgZmllbGQgYWxzbyBkdXBsaWNhdGVzIHRoZSBDV1QgJnF1b3Q7aXNzdWVkIGF0JnF1b3Q7 IHZhbHVlIGF0IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YWhs c3Ryb2VtLW9hdXRoLWNib3Itd2ViLXRva2VuLTAwI3NlY3Rpb24tMy4xLjYiPg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jvci13ZWItdG9rZW4t MDAjc2VjdGlvbi0zLjEuNjwvYT4uIFRoZSAmcXVvdDtvcGVyYXRpb24gdGltZSZxdW90OyB2YWx1 ZSBzaG91bGQgYmUgZGVsZXRlZCBmcm9tIHRoaXMgc3BlY2lmaWNhdGlvbiB0byBlbGltaW5hdGUg dGhpcyB1bm5lY2Vzc2FyeSBkdXBsaWNhdGlvbiAtIG5vdCBqdXN0IHJlbmFtZWQuPG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0Om5vbmUiPjxzcGFuIHN0 eWxlPSJjb2xvcjojNjY2NjY2Ij7igJQ8YnI+DQpSZXBseSB0byB0aGlzIGVtYWlsIGRpcmVjdGx5 IG9yIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3NlLXdnL2Nvc2UtaXNzdWVzL2lzc3Vl cy8xMyNpc3N1ZWNvbW1lbnQtMTY5NjgwNDAyIj4NCnZpZXcgaXQgb24gR2l0SHViPC9hPi48c3Bh biBzdHlsZT0iYm9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPjxpbWcg Ym9yZGVyPSIwIiB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9ImNp ZDppbWFnZTAwMS5qcGdAMDFEMTRDNkIuNkZFNjIzNjAiIGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBz ZW5kZXIuIj48L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB442CB3C86CF332C79B29066F5C90BY2PR03MB442namprd_-- --_004_BY2PR03MB442CB3C86CF332C79B29066F5C90BY2PR03MB442namprd_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=332; creation-date="Mon, 11 Jan 2016 20:27:37 GMT"; modification-date="Mon, 11 Jan 2016 20:27:37 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAABAAEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZq/9k= --_004_BY2PR03MB442CB3C86CF332C79B29066F5C90BY2PR03MB442namprd_-- From nobody Mon Jan 11 12:35:59 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E331A90FF for ; Mon, 11 Jan 2016 12:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3Fpl70HTWAYO for ; Mon, 11 Jan 2016 12:35:55 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D521A8A78 for ; Mon, 11 Jan 2016 12:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=efdx29Vx/ARt9X+zS6MOSIwJN5lm0IVH1ppOG3g6J48=; b=E4krX89mwMyMrATWr6+M/XusEBHAL4KObQoZ6wYGG5AGUMxB6ycFZigYBxc83LII5xS70oEsVwAXrkUvGjy4lADuPUI3TsNOaihkqgcts/upPv1/ma6Fmx23QnJkjUaM9/6DEOr5TPmWlRvk4lUeHGc2d4dlk+lLMRC8Cy9u/1M= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 11 Jan 2016 20:35:35 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0361.006; Mon, 11 Jan 2016 20:35:35 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [cose-issues] Require publicly visible stable specifications for IANA registrations (#39) Thread-Index: AQHRPFCAKn53T0H57U6o+cohh4mD05725P3g Date: Mon, 11 Jan 2016 20:35:34 +0000 Message-ID: References: <015801d13c50$1d1e24a0$575a6de0$@augustcellars.com> In-Reply-To: <015801d13c50$1d1e24a0$575a6de0$@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: [12.130.116.69] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:PBx4oisR4m047QcSSaBsX62NZhOeEXa7adSwDfvKIqEQaLPU07epsZdWgR1YEhn2PFSZ+cl9E5gYhKTbbMbn/rdVZspHzkpSU/cFTpx85TwFz9GYNYMaEFFQAazJGKNVvlxh1zA6yK9d4ZkimeAI+w==; 24:ex2WJU0owzcLZOa9vtpSpDAA8GDYnp7ch4ueeDX/O4tl9oI6o7SpldTeOxvX0TrsmO8nI7vIFjAExKWzAVo1dSvf8MVJgyAT32sRqDzX+xA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-ms-office365-filtering-correlation-id: 009bb920-22c0-478e-14d8-08d31ac6c213 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)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(199003)(377454003)(5004730100002)(5001960100002)(5003600100002)(81156007)(101416001)(11100500001)(15395725005)(6116002)(189998001)(122556002)(10400500002)(2950100001)(50986999)(33656002)(19580395003)(86612001)(5005710100001)(97736004)(10290500002)(1220700001)(586003)(1096002)(2906002)(15975445007)(66066001)(106116001)(92566002)(3846002)(4326007)(8990500004)(5002640100001)(77096005)(74316001)(76576001)(76176999)(54356999)(2900100001)(40100003)(110136002)(86362001)(99286002)(105586002)(87936001)(106356001)(10090500001)(5008740100001)(19580405001)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 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: 11 Jan 2016 20:35:34.9999 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] [cose-issues] Require publicly visible stable specifications for IANA registrations (#39) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 20:35:58 -0000 SSBkb24ndCB0aGluayB0aGF0IHJlZ2lzdGVyaW5nIENPU0UgdmFsdWVzIHdpdGhvdXQgbWFraW5n IGEgc3BlY2lmaWNhdGlvbiBwdWJsaWNseSBhdmFpbGFibGUgc28gdGhhdCB0aGUgcmVnaXN0ZXJl ZCB2YWx1ZSBjYW4gYmUgdW5kZXJzdG9vZCBhbmQgaGF2aW5nIHByaXZhdGUgaGVhZGVyIHBhcmFt ZXRlciBuYW1lcyBpbiBKT1NFLCB3aGljaCBhcmUgbm90IHJlZ2lzdGVyZWQsIGFyZSBlcXVpdmFs ZW50LiAgVGhlIGRpZmZlcmVuY2UgaXMgdGhhdCBpbiB0aGUgY3VycmVudCBDT1NFIG1ldGhvZG9s b2d5LCBpdCdzIHBvc3NpYmxlIHRvIGhhdmUgcmVnaXN0ZXJlZCB2YWx1ZXMgYnV0IG5vIHdheSBm b3IgaW1wbGVtZW50ZXJzIHRvIGZvbGxvdyBhIGxpbmsgZnJvbSB0aGUgcmVnaXN0cnkgdG8gdW5k ZXJzdGFuZCB3aGF0IHRoZSBtZWFuaW5nIG9mIHRoZSB2YWx1ZSBpcy4gIEluIEpPU0UsIGlmIGl0 J3MgcmVnaXN0ZXJlZCwgdGhlcmUncyBhbHdheXMgYSBsaW5rIGZyb20gdGhlIHJlZ2lzdHJ5IHRv IHRoZSBkZWZpbml0aW9uLiAgVGhhdCBzZWVtcyBhIGxvdCBtb3JlIGNvbnNpc3RlbnQgYW5kIHVz ZWZ1bCB0byBtZSwgaGVuY2UgbXkgcmVxdWVzdCBmb3IgdGhlIGNoYW5nZS4NCg0KSSdtIGZpbmUg d2l0aCBwcml2YXRlIHZhbHVlcyBmb3IgcHJpdmF0ZSB1c2FnZXMuICBKdXN0IGRvbid0IHJlZ2lz dGVyIHRoZW0uICBSZWdpc3RyYXRpb25zIHNob3VsZCBhbGwgYmUgc3BlY2lmaWNhdGlvbi1yZXF1 aXJlZC4NCg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEppbSBTY2hhYWQgW21haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tXSANClNlbnQ6IE1vbmRh eSwgRGVjZW1iZXIgMjEsIDIwMTUgNDozMiBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBjb3NlQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW2Nvc2Ut aXNzdWVzXSBSZXF1aXJlIHB1YmxpY2x5IHZpc2libGUgc3RhYmxlIHNwZWNpZmljYXRpb25zIGZv ciBJQU5BIHJlZ2lzdHJhdGlvbnMgKCMzOSkNCg0KTWlrZSwNCg0KSSB3YXMgd29uZGVyaW5nIGlm IHlvdSBjb3VsZCBhZGRyZXNzIHdoYXQgbWlnaHQgYmUgc2VlbiBhcyBhIGNoYW5nZSBpbiB5b3Vy IGF0dGl0dWRlIHRvIHRoaXMgb3ZlciB0aW1lLg0KDQpUaGUgSk9TRSBzcGVjaWZpY2F0aW9ucyBh bGxvdyBmb3IgYSBwcml2YXRlbHkgZGVmaW5lZCBoZWFkZXIgZmllbGQgdG8gYmUgY3JlYXRlZC4N Cg0KU29tZXRoaW5nIHNpbWlsYXIgdG8gdGhlIGN1cnJlbnQgQ09TRSBhbGxvY2F0aW9ucyBpcyBk b25lIGluIHRoZSBKT1NFIGRvY3VtZW50cyBieSB0aGUgZm9sbG93aW5nOg0KDQoNClJlZ2lzdGVy ZWQgSGVhZGVyIFBhcmFtZXRlciBOYW1lcyBpbiBKT1NFOiAgVGhpcyBjb3JyZXNwb25kcyB0byB0 aGUgZ2VuZXJhbCBhcmVhIG9mIFNwZWNpZmljYXRpb24gUmVxdWlyZWQgYXNzaWdubWVudCBhcmVh IG9mIENPU0UgZG9jdW1lbnRzLiAgSSBub3RlIHRoYXQgYWx0aG91Z2ggYSByZWZlcmVuY2UgdG8g YSBkb2N1bWVudCBpcyByZXF1aXJlZCwgaXQgaW1wbGljaXRseSBidXQgZG9lcyBub3QgZXhwbGlj aXRseSByZXF1aXJlIHRoYXQgdGhlIGRvY3VtZW50IGJlIHB1YmxpY2x5IGF2YWlsYWJsZS4gDQoN ClB1YmxpYyBIZWFkZXIgUGFyYW1ldGVyIE5hbWVzIGluIEpPU0U6IFRoaXMgY29ycmVzcG9uZCB0 byB0aGUgc2V0IG9mIGZpcnN0LWNvbWUsIGZpcnN0IHNlcnZlIGFzc2lnbm1lbnQgYXJlYSBvZiBD T1NFIGRvY3VtZW50cy4gIEpPU0UgZGVhbHMgd2l0aCB0aGlzIGJ5IHNheWluZyB0aGF0IGl0IHNo b3VsZCBiZSBjb2xsaXNpb24gcmVzaXN0YW50IGJ5IHByZWZpeGluZyAob3Igc29tZSBvdGhlciBt ZXRob2QpIHRvIG1ha2UgdGhlIG5hbWUgc3RhdGlzdGljYWxseSB1bmlxdWUuICBGb3IgQ09TRSBp dCB3b3VsZCBub3QgYmUgcG9zc2libGUgdG8gaGF2ZSBhbnkgZGVncmVlIG9mIHVuaXF1ZW5lc3Mg b2YgdGhlIGhlYWRlcnMgaW4gdGhlIHNhbWUgd2F5IHdoaWxlIHN0aWxsIG1haW50YWluaW5nIHRo ZSBkZXNpcmUgdG8gaGF2ZSB2ZXJ5IHNob3J0IGlkZW50aWZpZXJzLiAgVGhlcmUgaXMgYSBiaWcg ZGlmZmVyZW5jZSBpbiBzaXplIGJldHdlZW4gImh0dHA6Ly9leGFtcGxlLm9yZy9DT1NFL2Zvb2Jh ciIgYW5kIDB4MTAwMDAwIHdoZW4gZG9pbmcgdGhlIGVuY29kaW5ncyBpbiBDQk9SLg0KDQpQcml2 YXRlIEhlYWRlciBQYXJhbWV0ZXIgTmFtZXMgaW4gSk9TRTogIFRoaXMgY29ycmVzcG9uZHMgdG8g dGhlIHByaXZhdGUgcmVnaXN0cnkgYXNzaWdubWVudCBhcmVhIG9mIENPU0UgZG9jdW1lbnRzLg0K DQoNCkl0IHdvdWxkIGFwcGVhciBmcm9tIHRoaXMgdGhhdCB0aGVyZSBpcyBhbiBpbXBsaWNpdCBy ZWdpc3RyeSBhcmVhIGZvciBKT1NFIHdoaWNoIGFsbG93cyBmb3IgYSBzZWN0aW9uIGhlYWRlciBw YXJhbWV0ZXJzIHdoaWNoIGRvZXMgbm90IGhhdmUgcHVibGljbHkgYXZhaWxhYmxlIHNwZWNpZmlj YXRpb25zIHdoZW4gaW1wbGljaXRseSByZWdpc3RlcmVkLiAgVG8gd2l0LCB0aGUgUHVibGljIEhl YWRlciBQYXJhbWV0ZXIgTmFtZXMuDQoNCkkgYW0gbm90IHN1cmUgaWYgdGhpcyByZWFsbHkgcmVw cmVzZW50cyBhIGNoYW5nZSBpbiB5b3VyIG9waW5pb25zIG9yIGlmIHlvdSBoYXZlIGp1c3Qgbm90 IGNvbnNpZGVyZWQgdGhlc2UgYXMgYmVpbmcgZXF1aXZhbGVudC4NCg0KSmltDQoNCg0K From nobody Mon Jan 11 14:28:10 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DAC1AC3E4 for ; Mon, 11 Jan 2016 14:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 OuieVW32i8VV for ; Mon, 11 Jan 2016 14:28:07 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5921AC3D1 for ; Mon, 11 Jan 2016 14:28:07 -0800 (PST) Date: Mon, 11 Jan 2016 14:28:06 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1452551286; bh=kHtsTrdR5ipFoGIHxFNcHD2arkGh7Djq6c3cYbq+32E=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xbCXnSowdB5YV0dkVoLAQ3Wv3I4sxHme+Vv+CaKDVdBxCS2EgcizzNhcntrWzczrD WjBGbk2etk1TklOxSBEnGaUfHT/TG4bIXuz53F66BYrepj4kWKu7iECdkkoRs9Rd1+ DEd7Z9vn9Cl/iRiaDSfw6atfvefS58z+cO/SRcxQ= From: Mike Jones To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56942c762024a_437d3f818c3672a086076"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: selfissued X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] Require publicly visible stable specifications for IANA registrations (#39) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 22:28:09 -0000 ----==_mimepart_56942c762024a_437d3f818c3672a086076 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit See the thread with Jim and I discussing this at https://mailarchive.ietf.org/arch/msg/cose/okLF3q9KvRg-FmacxJlJKCytJJE. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/39#issuecomment-170711529 ----==_mimepart_56942c762024a_437d3f818c3672a086076 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

See the thread with Jim and I discussing this at https://mailarchive.ietf.org/arch/msg/cose/okLF3q9KvRg-FmacxJlJKCytJJE.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_56942c762024a_437d3f818c3672a086076-- From nobody Mon Jan 11 16:09:56 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3A41A9061 for ; Mon, 11 Jan 2016 16:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 o8RV6IWJ1SHU for ; Mon, 11 Jan 2016 16:09:52 -0800 (PST) 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 20AFB1A8A8F for ; Mon, 11 Jan 2016 16:09:52 -0800 (PST) Received: from hebrews (ip-64-134-132-3.public.wayport.net [64.134.132.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 1502438EAA; Mon, 11 Jan 2016 16:09:51 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" References: <00b401d14a72$eccb5210$c661f630$@augustcellars.com> In-Reply-To: Date: Mon, 11 Jan 2016 16:07:13 -0800 Message-ID: <040d01d14ccd$30bb4140$9231c3c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_040E_01D14C8A.229A7240" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQHnVbEEf4RRBeXSolS/kzUPbuZGtgLLHPuuAcn9m6IDIlW9kp6NM0Qw Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Move_=E2=80=9Ccreation_time?= =?utf-8?b?4oCdIHZhbHVlIHRvIHRoZSBwYXlsb2FkICgjMTMp?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 00:09:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_040E_01D14C8A.229A7240 Content-Type: multipart/alternative; boundary="----=_NextPart_001_040F_01D14C8A.229A7240" ------=_NextPart_001_040F_01D14C8A.229A7240 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I will point out that this is designed to wrap things other than CWT. = If you are wrapping a sensor reading then there is not a CWT involved at = that point. =20 Jim =20 =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Monday, January 11, 2016 12:28 PM To: Jim Schaad Cc: cose@ietf.org Subject: RE: [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D value to = the payload (#13) =20 I have now. This still feels like unnecessary duplication of the CBOR = Web Token (CWT) =E2=80=9Ciat=E2=80=9D (issued at) = claim to me, but I=E2=80=99m curious what others think. =20 -- Mike =20 From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Friday, January 8, 2016 4:16 PM To: Mike Jones > Cc: cose@ietf.org =20 Subject: RE: [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D value to = the payload (#13) =20 Did you read the change in the text that was made at the same time? = It states that =E2=80=9CThe field is primarily intended to be to be used = for countersignatures, however it can additionally be used for replay = detection as well.=E2=80=9D It is not possible to put the time field in = the content for a countersignature as there is no customizable content = in that case. =20 =20 =20 From: Mike Jones [mailto:notifications@github.com]=20 Sent: Thursday, January 07, 2016 6:34 AM To: cose-wg/cose-issues > Cc: Jim Schaad > Subject: Re: [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D value to = the payload (#13) =20 Changing the name does not address the core issue that this field is = solely for use as defined by particular applications and has no = associated COSE processing rules. That says that it belongs in the CBOR = Web Token draft, which defines application payload fields, rather than = COSE messages spec. This field also duplicates the CWT "issued at" value at = https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#sect= ion-3.1.6. The "operation time" value should be deleted from this = specification to eliminate this unnecessary duplication - not just = renamed. =E2=80=94 Reply to this email directly or view it on GitHub = = . ------=_NextPart_001_040F_01D14C8A.229A7240 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I will point out that this is designed to wrap things other than = CWT.=C2=A0 If you are wrapping a sensor reading then there is not a CWT = involved at that point.

 

Jim

 

 

From:<= /b> = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Monday, = January 11, 2016 12:28 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = cose@ietf.org
Subject: RE: [cose-issues] Move = =E2=80=9Ccreation time=E2=80=9D value to the payload = (#13)

 

I have now.  This still feels like unnecessary duplication of the = CBOR Web Token (CWT) =E2=80=9Ciat=E2=80=9D (issued = at) claim to me, but I=E2=80=99m curious what others = think.

 

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

 

From:<= /b> = Jim Schaad [mailto:ietf@augustcellars.com]=
Sent: Friday, January 8, 2016 4:16 PM
To: Mike = Jones <Michael.Jones@microsoft.com>
Cc: cose@ietf.org
Subject: RE: = [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D value to the payload = (#13)

 

Did you read the change in the text that was made at the same = time?    It states that =E2=80=9CThe field is primarily = intended to be to be used for countersignatures, however it can = additionally be used for replay detection as well.=E2=80=9D  It is = not possible to put the time field in the content for a countersignature = as there is no customizable content in that = case.

 

 

 

From:<= /b> = Mike Jones [mailto:notifications@github.com<= /a>]
Sent: Thursday, January 07, 2016 6:34 AM
To: = cose-wg/cose-issues <cose-issues@noreply.github= .com>
Cc: Jim Schaad <ietf@augustcellars.com>
= Subject: Re: [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D = value to the payload (#13)

 

Changing the name does not = address the core issue that this field is solely for use as defined by = particular applications and has no associated COSE processing rules. = That says that it belongs in the CBOR Web Token draft, which defines = application payload fields, rather than COSE messages = spec.

This field also duplicates the CWT "issued = at" value at https://tools.ietf.org/html/draft-wahlstroem-oauth-cbo= r-web-token-00#section-3.1.6. The "operation time" value = should be deleted from this specification to eliminate this unnecessary = duplication - not just renamed.

=E2=80=94
Reply to this email directly or view it on GitHub.3D"Image

------=_NextPart_001_040F_01D14C8A.229A7240-- ------=_NextPart_000_040E_01D14C8A.229A7240 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAABAAEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZq/9k= ------=_NextPart_000_040E_01D14C8A.229A7240-- From nobody Mon Jan 11 16:50:13 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97BA1A1B3C for ; Mon, 11 Jan 2016 16:50:11 -0800 (PST) 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 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 N_fnPd7eD63o for ; Mon, 11 Jan 2016 16:50:10 -0800 (PST) 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 198901A1B24 for ; Mon, 11 Jan 2016 16:50:10 -0800 (PST) Received: from hebrews (ip-64-134-132-3.public.wayport.net [64.134.132.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 7AB4238EAA; Mon, 11 Jan 2016 16:50:09 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" References: <015801d13c50$1d1e24a0$575a6de0$@augustcellars.com> In-Reply-To: Date: Mon, 11 Jan 2016 16:47:32 -0800 Message-ID: <042901d14cd2$d2338550$769a8ff0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQIh77xEt34fKYVFI50LfMLhy5sRZQE/4W0WAYWHcxIBvKBitZ4xtSkw Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] [cose-issues] Require publicly visible stable specifications for IANA registrations (#39) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 00:50:12 -0000 So you are saying that there is not a problem as long as we don't = register the fact that we are using a code point for identifying the = private item we are using. Even though we might be using the same code = point to mean different things and a message set by my system might be = received by your system. The need for registration is because there is not the ability that JOSE = has where there is a statement about trying to use private identifiers = that are somehow scoped to be private. The world of identifiers for = COSE maps closer to that of the public but unregistered world of JOSE. Jim > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Monday, January 11, 2016 12:36 PM > To: Jim Schaad > Cc: cose@ietf.org > Subject: RE: [cose-issues] Require publicly visible stable = specifications for IANA > registrations (#39) >=20 > I don't think that registering COSE values without making a = specification publicly > available so that the registered value can be understood and having = private > header parameter names in JOSE, which are not registered, are = equivalent. The > difference is that in the current COSE methodology, it's possible to = have > registered values but no way for implementers to follow a link from = the registry > to understand what the meaning of the value is. In JOSE, if it's = registered, > there's always a link from the registry to the definition. That seems = a lot more > consistent and useful to me, hence my request for the change. >=20 > I'm fine with private values for private usages. Just don't register = them. > Registrations should all be specification-required. >=20 > -- Mike >=20 > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Monday, December 21, 2015 4:32 PM > To: Mike Jones > Cc: cose@ietf.org > Subject: RE: [cose-issues] Require publicly visible stable = specifications for IANA > registrations (#39) >=20 > Mike, >=20 > I was wondering if you could address what might be seen as a change in = your > attitude to this over time. >=20 > The JOSE specifications allow for a privately defined header field to = be created. >=20 > Something similar to the current COSE allocations is done in the JOSE = documents > by the following: >=20 >=20 > Registered Header Parameter Names in JOSE: This corresponds to the = general > area of Specification Required assignment area of COSE documents. I = note that > although a reference to a document is required, it implicitly but does = not > explicitly require that the document be publicly available. >=20 > Public Header Parameter Names in JOSE: This correspond to the set of = first- > come, first serve assignment area of COSE documents. JOSE deals with = this by > saying that it should be collision resistant by prefixing (or some = other method) to > make the name statistically unique. For COSE it would not be possible = to have > any degree of uniqueness of the headers in the same way while still = maintaining > the desire to have very short identifiers. There is a big difference = in size > between "http://example.org/COSE/foobar" and 0x100000 when doing the > encodings in CBOR. >=20 > Private Header Parameter Names in JOSE: This corresponds to the = private > registry assignment area of COSE documents. >=20 >=20 > It would appear from this that there is an implicit registry area for = JOSE which > allows for a section header parameters which does not have publicly = available > specifications when implicitly registered. To wit, the Public Header = Parameter > Names. >=20 > I am not sure if this really represents a change in your opinions or = if you have > just not considered these as being equivalent. >=20 > Jim >=20 From nobody Mon Jan 11 19:43:40 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44ED41ACDAB for ; Mon, 11 Jan 2016 19:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 yivtYcpZ8tDu for ; Mon, 11 Jan 2016 19:43:35 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFFC11ACDA1 for ; Mon, 11 Jan 2016 19:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FpUX1x8D6TePT/s/sKjrWXvB34jQo55PwkFftZ95sXY=; b=nCZY2VTLXU6lcPIZlSyr+MQSpITftAGfTAwAcm7E7Hs9CZa5s1vWH1bnar8f1M3eGlbu83eC90RJOy4Ue0yXMpIwPuhYHXhRb1C4Y5qdVQa5iXCmA6cqsRB3YSY9brWN39C0YrEX/xzky1uUsGlYgU5ULkwTYhfgkpL9DrXk31M= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 12 Jan 2016 03:43:29 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0361.006; Tue, 12 Jan 2016 03:43:29 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: =?utf-8?B?W2Nvc2UtaXNzdWVzXSBNb3ZlIOKAnGNyZWF0aW9uIHRpbWXigJ0gdmFsdWUg?= =?utf-8?Q?to_the_payload_(#13)?= Thread-Index: AQHnVbEEf4RRBeXSolS/kzUPbuZGtgLLHPuunq/hEOCABHaKgIAAPnyAgAA7WbA= Date: Tue, 12 Jan 2016 03:43:29 +0000 Message-ID: References: <00b401d14a72$eccb5210$c661f630$@augustcellars.com> <040d01d14ccd$30bb4140$9231c3c0$@augustcellars.com> In-Reply-To: <040d01d14ccd$30bb4140$9231c3c0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [107.16.91.73] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:IF7GsuWDSxVOXP38d3EUMgk15/Tum8/Dp79CARwifJgVVjp0wyGi9ZSgs4xLRl+j4+LO6YTPddMJBa8bQyCakEdoVJqvkd0hwqlYHZzDEMqcG57OqCTZ741h/nwEw0IJTZY0YIahy/gSAsSW0YZiYA==; 24:F6Xt4XsuyjJaIvXsqx3F8vI1UUlopq6JgiH1a6BoO9KdkVzyfWC2UKv4H+2xJl6GZsfCddIMSfnXQmEDxEMRHMRXWwT2W7PlmrusMHwuxoY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-ms-office365-filtering-correlation-id: d51b02e2-31a8-4147-c8e0-08d31b028949 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(102615245)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(189002)(1096002)(586003)(40100003)(16236675004)(33656002)(105586002)(50986999)(54356999)(81156007)(86362001)(8990500004)(86612001)(97736004)(99286002)(19627595001)(106116001)(2900100001)(101416001)(5003600100002)(10090500001)(122556002)(2906002)(18206015028)(76576001)(10400500002)(66066001)(5004730100002)(5002640100001)(5008740100001)(19580395003)(15975445007)(76176999)(5005710100001)(790700001)(189998001)(110136002)(102836003)(2950100001)(19617315012)(19580405001)(93886004)(3846002)(87936001)(106356001)(92566002)(17760045003)(77096005)(99936001)(4326007)(1220700001)(6116002)(74316001)(10290500002)(19625215002)(5001960100002)(11100500001)(19609705001)(19300405004)(7099028); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_BY2PR03MB442B12BA81B732F47DC3524F5CA0BY2PR03MB442namprd_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2016 03:43:29.4070 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Move_=E2=80=9Ccreation_time?= =?utf-8?b?4oCdIHZhbHVlIHRvIHRoZSBwYXlsb2FkICgjMTMp?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 03:43:39 -0000 --_004_BY2PR03MB442B12BA81B732F47DC3524F5CA0BY2PR03MB442namprd_ Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442B12BA81B732F47DC3524F5CA0BY2PR03MB442namprd_" --_000_BY2PR03MB442B12BA81B732F47DC3524F5CA0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmFpciBlbm91Z2guICBCdXQgdGhlcmXigJlzIG5vdGhpbmcgc3RvcHBpbmcgdGhlIHNlbnNvciBh cHBsaWNhdGlvbiBmcm9tIGRlZmluaW5nIGEgaGVhZGVyIHBhcmFtZXRlciB0aGF0IGRvZXMgZXhh Y3RseSB3aGF0IGl0IG5lZWRzIHRvIGRvLCByZWdpc3RlcmluZyBpdCwgYW5kIHVzaW5nLiAgVGhl IOKAnGNyZWF0aW9uIHRpbWXigJ0gcGFyYW1ldGVyIGltcGxpZXMgc3luY2hyb25pemVkIGNsb2Nr cywgd2hpY2ggcHJvYmFibHkgdGFrZXMgaXQgb3V0IG9mIGFwcGxpY2FiaWxpdHkgaW4gdGhlIHNl bnNvciBzcGFjZSBhbHJlYWR5LiAgVGhlcmUgYXJlIGxvdHMgb2YgZ29vZCBhcHBsaWNhdGlvbi1z cGVjaWZpYyBjaG9pY2VzLg0KDQpUaGUgYnJpZ2h0IGxpbmUgdGVzdCBmb3IgbWUgdGhhdCBzYXlz IHRoYXQgdGhpcyBoZWFkZXIgcGFyYW1ldGVyIGRvZXNu4oCZdCBiZWxvbmcgaW4gdGhlIGNyeXB0 byBzcGVjIGlzIHRoYXQgdGhlcmUgYXJlIG5vIGNyeXB0b2dyYXBoaWMgcHJvY2Vzc2luZyBydWxl cyBmb3IgaXQuICBUaGF0IHNheXMgdGhhdCBpdOKAmXMgYXBwbGljYXRpb24gZGF0YSDigJMgbm90 IGNyeXB0byBkYXRhLiAgQW5kIGFzIHN1Y2gsIGl0IHNob3VsZCBiZSBkZWZpbmVkIGJ5IGFwcGxp Y2F0aW9ucyDigJMgbm90IHRoZSBjcnlwdG8gc3BlYy4NCg0KUGxlYXNlIHJlbW92ZSB0aGlzIHBh cmFtZXRlci4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSmltIFNjaGFhZCBbbWFpbHRvOmlldGZAYXVn dXN0Y2VsbGFycy5jb21dDQpTZW50OiBNb25kYXksIEphbnVhcnkgMTEsIDIwMTYgNDowNyBQTQ0K VG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBjb3NlQGll dGYub3JnDQpTdWJqZWN0OiBSRTogW2Nvc2UtaXNzdWVzXSBNb3ZlIOKAnGNyZWF0aW9uIHRpbWXi gJ0gdmFsdWUgdG8gdGhlIHBheWxvYWQgKCMxMykNCg0KSSB3aWxsIHBvaW50IG91dCB0aGF0IHRo aXMgaXMgZGVzaWduZWQgdG8gd3JhcCB0aGluZ3Mgb3RoZXIgdGhhbiBDV1QuICBJZiB5b3UgYXJl IHdyYXBwaW5nIGEgc2Vuc29yIHJlYWRpbmcgdGhlbiB0aGVyZSBpcyBub3QgYSBDV1QgaW52b2x2 ZWQgYXQgdGhhdCBwb2ludC4NCg0KSmltDQoNCg0KRnJvbTogTWlrZSBKb25lcyBbbWFpbHRvOk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbV0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxMSwgMjAx NiAxMjoyOCBQTQ0KVG86IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb208bWFpbHRv OmlldGZAYXVndXN0Y2VsbGFycy5jb20+Pg0KQ2M6IGNvc2VAaWV0Zi5vcmc8bWFpbHRvOmNvc2VA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW2Nvc2UtaXNzdWVzXSBNb3ZlIOKAnGNyZWF0aW9uIHRp bWXigJ0gdmFsdWUgdG8gdGhlIHBheWxvYWQgKCMxMykNCg0KSSBoYXZlIG5vdy4gIFRoaXMgc3Rp bGwgZmVlbHMgbGlrZSB1bm5lY2Vzc2FyeSBkdXBsaWNhdGlvbiBvZiB0aGUgQ0JPUiBXZWIgVG9r ZW4gKENXVCkg4oCcaWF04oCdIChpc3N1ZWQgYXQpPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC13YWhsc3Ryb2VtLWFjZS1jYm9yLXdlYi10b2tlbi0wMCNzZWN0aW9uLTMuMS42PiBj bGFpbSB0byBtZSwgYnV0IEnigJltIGN1cmlvdXMgd2hhdCBvdGhlcnMgdGhpbmsuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCkZyb206IEppbSBTY2hhYWQgW21haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tXQ0K U2VudDogRnJpZGF5LCBKYW51YXJ5IDgsIDIwMTYgNDoxNiBQTQ0KVG86IE1pa2UgSm9uZXMgPE1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPj4NCkNjOiBjb3NlQGlldGYub3JnPG1haWx0bzpjb3NlQGlldGYub3JnPg0KU3ViamVjdDog UkU6IFtjb3NlLWlzc3Vlc10gTW92ZSDigJxjcmVhdGlvbiB0aW1l4oCdIHZhbHVlIHRvIHRoZSBw YXlsb2FkICgjMTMpDQoNCkRpZCB5b3UgcmVhZCB0aGUgY2hhbmdlIGluIHRoZSB0ZXh0IHRoYXQg d2FzIG1hZGUgYXQgdGhlIHNhbWUgdGltZT8gICAgSXQgc3RhdGVzIHRoYXQg4oCcVGhlIGZpZWxk IGlzIHByaW1hcmlseSBpbnRlbmRlZCB0byBiZSB0byBiZSB1c2VkIGZvciBjb3VudGVyc2lnbmF0 dXJlcywgaG93ZXZlciBpdCBjYW4gYWRkaXRpb25hbGx5IGJlIHVzZWQgZm9yIHJlcGxheSBkZXRl Y3Rpb24gYXMgd2VsbC7igJ0gIEl0IGlzIG5vdCBwb3NzaWJsZSB0byBwdXQgdGhlIHRpbWUgZmll bGQgaW4gdGhlIGNvbnRlbnQgZm9yIGEgY291bnRlcnNpZ25hdHVyZSBhcyB0aGVyZSBpcyBubyBj dXN0b21pemFibGUgY29udGVudCBpbiB0aGF0IGNhc2UuDQoNCg0KDQpGcm9tOiBNaWtlIEpvbmVz IFttYWlsdG86bm90aWZpY2F0aW9uc0BnaXRodWIuY29tXQ0KU2VudDogVGh1cnNkYXksIEphbnVh cnkgMDcsIDIwMTYgNjozNCBBTQ0KVG86IGNvc2Utd2cvY29zZS1pc3N1ZXMgPGNvc2UtaXNzdWVz QG5vcmVwbHkuZ2l0aHViLmNvbTxtYWlsdG86Y29zZS1pc3N1ZXNAbm9yZXBseS5naXRodWIuY29t Pj4NCkNjOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0bzppZXRmQGF1 Z3VzdGNlbGxhcnMuY29tPj4NClN1YmplY3Q6IFJlOiBbY29zZS1pc3N1ZXNdIE1vdmUg4oCcY3Jl YXRpb24gdGltZeKAnSB2YWx1ZSB0byB0aGUgcGF5bG9hZCAoIzEzKQ0KDQoNCkNoYW5naW5nIHRo ZSBuYW1lIGRvZXMgbm90IGFkZHJlc3MgdGhlIGNvcmUgaXNzdWUgdGhhdCB0aGlzIGZpZWxkIGlz IHNvbGVseSBmb3IgdXNlIGFzIGRlZmluZWQgYnkgcGFydGljdWxhciBhcHBsaWNhdGlvbnMgYW5k IGhhcyBubyBhc3NvY2lhdGVkIENPU0UgcHJvY2Vzc2luZyBydWxlcy4gVGhhdCBzYXlzIHRoYXQg aXQgYmVsb25ncyBpbiB0aGUgQ0JPUiBXZWIgVG9rZW4gZHJhZnQsIHdoaWNoIGRlZmluZXMgYXBw bGljYXRpb24gcGF5bG9hZCBmaWVsZHMsIHJhdGhlciB0aGFuIENPU0UgbWVzc2FnZXMgc3BlYy4N Cg0KVGhpcyBmaWVsZCBhbHNvIGR1cGxpY2F0ZXMgdGhlIENXVCAiaXNzdWVkIGF0IiB2YWx1ZSBh dCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9y LXdlYi10b2tlbi0wMCNzZWN0aW9uLTMuMS42LiBUaGUgIm9wZXJhdGlvbiB0aW1lIiB2YWx1ZSBz aG91bGQgYmUgZGVsZXRlZCBmcm9tIHRoaXMgc3BlY2lmaWNhdGlvbiB0byBlbGltaW5hdGUgdGhp cyB1bm5lY2Vzc2FyeSBkdXBsaWNhdGlvbiAtIG5vdCBqdXN0IHJlbmFtZWQuDQoNCuKAlA0KUmVw bHkgdG8gdGhpcyBlbWFpbCBkaXJlY3RseSBvciB2aWV3IGl0IG9uIEdpdEh1YjxodHRwczovL2dp dGh1Yi5jb20vY29zZS13Zy9jb3NlLWlzc3Vlcy9pc3N1ZXMvMTMjaXNzdWVjb21tZW50LTE2OTY4 MDQwMj4uDQo= --_000_BY2PR03MB442B12BA81B732F47DC3524F5CA0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMwMDIwNjA7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+RmFpciBlbm91Z2guJm5ic3A7IEJ1dCB0 aGVyZeKAmXMgbm90aGluZyBzdG9wcGluZyB0aGUgc2Vuc29yIGFwcGxpY2F0aW9uIGZyb20gZGVm aW5pbmcgYSBoZWFkZXIgcGFyYW1ldGVyIHRoYXQgZG9lcyBleGFjdGw8YSBuYW1lPSJfTWFpbEVu ZENvbXBvc2UiPnkgd2hhdCBpdCBuZWVkcyB0bw0KIGRvLCByZWdpc3RlcmluZyBpdCwgYW5kIHVz aW5nLiZuYnNwOyBUaGUg4oCcY3JlYXRpb24gdGltZeKAnSBwYXJhbWV0ZXIgaW1wbGllcyBzeW5j aHJvbml6ZWQgY2xvY2tzLCB3aGljaCBwcm9iYWJseSB0YWtlcyBpdCBvdXQgb2YgYXBwbGljYWJp bGl0eSBpbiB0aGUgc2Vuc29yIHNwYWNlIGFscmVhZHkuJm5ic3A7IFRoZXJlIGFyZSBsb3RzIG9m IGdvb2QgYXBwbGljYXRpb24tc3BlY2lmaWMgY2hvaWNlcy48bzpwPjwvbzpwPjwvYT48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj5UaGUgYnJpZ2h0IGxpbmUgdGVzdCBmb3IgbWUgdGhhdCBzYXlzIHRoYXQgdGhpcyBoZWFk ZXIgcGFyYW1ldGVyIGRvZXNu4oCZdCBiZWxvbmcgaW4gdGhlIGNyeXB0byBzcGVjIGlzIHRoYXQg dGhlcmUgYXJlDQogbm8gY3J5cHRvZ3JhcGhpYyBwcm9jZXNzaW5nIHJ1bGVzIGZvciBpdC4mbmJz cDsgVGhhdCBzYXlzIHRoYXQgaXTigJlzIGFwcGxpY2F0aW9uIGRhdGEg4oCTIG5vdCBjcnlwdG8g ZGF0YS4mbmJzcDsgQW5kIGFzIHN1Y2gsIGl0IHNob3VsZCBiZSBkZWZpbmVkIGJ5IGFwcGxpY2F0 aW9ucyDigJMgbm90IHRoZSBjcnlwdG8gc3BlYy48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVu ZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw Ij5QbGVhc2UgcmVtb3ZlIHRoaXMgcGFyYW1ldGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwv cD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSmltIFNj aGFhZCBbbWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g TW9uZGF5LCBKYW51YXJ5IDExLCAyMDE2IDQ6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9u ZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGNv c2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtjb3NlLWlzc3Vlc10gTW92ZSDi gJxjcmVhdGlvbiB0aW1l4oCdIHZhbHVlIHRvIHRoZSBwYXlsb2FkICgjMTMpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkkgd2lsbCBwb2ludCBvdXQgdGhhdCB0aGlzIGlzIGRlc2lnbmVkIHRvIHdyYXAg dGhpbmdzIG90aGVyIHRoYW4gQ1dULiZuYnNwOyBJZiB5b3UgYXJlIHdyYXBwaW5nIGEgc2Vuc29y IHJlYWRpbmcgdGhlbiB0aGVyZSBpcyBub3QgYSBDV1QgaW52b2x2ZWQgYXQgdGhhdCBwb2ludC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkppbTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNaWtlIEpvbmVzIFs8YSBocmVmPSJtYWlsdG86TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5tYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMTEsIDIwMTYgMTI6 MjggUE08YnI+DQo8Yj5Ubzo8L2I+IEppbSBTY2hhYWQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRm QGF1Z3VzdGNlbGxhcnMuY29tIj5pZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpjb3NlQGlldGYub3JnIj5jb3NlQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW2Nvc2UtaXNzdWVzXSBNb3ZlIOKAnGNyZWF0aW9u IHRpbWXigJ0gdmFsdWUgdG8gdGhlIHBheWxvYWQgKCMxMyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ SSBoYXZlIG5vdy4mbmJzcDsgVGhpcyBzdGlsbCBmZWVscyBsaWtlIHVubmVjZXNzYXJ5IGR1cGxp Y2F0aW9uIG9mIHRoZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXdhaGxzdHJvZW0tYWNlLWNib3Itd2ViLXRva2VuLTAwI3NlY3Rpb24tMy4xLjYiPg0KQ0JPUiBX ZWIgVG9rZW4gKENXVCkg4oCcaWF04oCdIChpc3N1ZWQgYXQpPC9hPiBjbGFpbSB0byBtZSwgYnV0 IEnigJltIGN1cmlvdXMgd2hhdCBvdGhlcnMgdGhpbmsuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gSmltIFNjaGFhZCBbPGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2Vs bGFycy5jb20iPm1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPl0NCjxicj4NCjxiPlNl bnQ6PC9iPiBGcmlkYXksIEphbnVhcnkgOCwgMjAxNiA0OjE2IFBNPGJyPg0KPGI+VG86PC9iPiBN aWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t Ij5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEg aHJlZj0ibWFpbHRvOmNvc2VAaWV0Zi5vcmciPmNvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJFOiBbY29zZS1pc3N1ZXNdIE1vdmUg4oCcY3JlYXRpb24gdGltZeKAnSB2YWx1 ZSB0byB0aGUgcGF5bG9hZCAoIzEzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5EaWQgeW91IHJlYWQg dGhlIGNoYW5nZSBpbiB0aGUgdGV4dCB0aGF0IHdhcyBtYWRlIGF0IHRoZSBzYW1lIHRpbWU/Jm5i c3A7ICZuYnNwOyZuYnNwO0l0IHN0YXRlcyB0aGF0IOKAnFRoZSBmaWVsZCBpcyBwcmltYXJpbHkg aW50ZW5kZWQgdG8gYmUgdG8gYmUgdXNlZCBmb3IgY291bnRlcnNpZ25hdHVyZXMsDQogaG93ZXZl ciBpdCBjYW4gYWRkaXRpb25hbGx5IGJlIHVzZWQgZm9yIHJlcGxheSBkZXRlY3Rpb24gYXMgd2Vs bC7igJ0mbmJzcDsgSXQgaXMgbm90IHBvc3NpYmxlIHRvIHB1dCB0aGUgdGltZSBmaWVsZCBpbiB0 aGUgY29udGVudCBmb3IgYSBjb3VudGVyc2lnbmF0dXJlIGFzIHRoZXJlIGlzIG5vIGN1c3RvbWl6 YWJsZSBjb250ZW50IGluIHRoYXQgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1pa2UgSm9uZXMgWzxhIGhyZWY9Im1haWx0 bzpub3RpZmljYXRpb25zQGdpdGh1Yi5jb20iPm1haWx0bzpub3RpZmljYXRpb25zQGdpdGh1Yi5j b208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDA3LCAyMDE2IDY6 MzQgQU08YnI+DQo8Yj5Ubzo8L2I+IGNvc2Utd2cvY29zZS1pc3N1ZXMgJmx0OzxhIGhyZWY9Im1h aWx0bzpjb3NlLWlzc3Vlc0Bub3JlcGx5LmdpdGh1Yi5jb20iPmNvc2UtaXNzdWVzQG5vcmVwbHku Z2l0aHViLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKaW0gU2NoYWFkICZsdDs8YSBocmVm PSJtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSI+aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY29zZS1pc3N1ZXNdIE1vdmUg4oCcY3Jl YXRpb24gdGltZeKAnSB2YWx1ZSB0byB0aGUgcGF5bG9hZCAoIzEzKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwPkNoYW5naW5nIHRoZSBuYW1lIGRvZXMgbm90IGFkZHJlc3MgdGhlIGNvcmUg aXNzdWUgdGhhdCB0aGlzIGZpZWxkIGlzIHNvbGVseSBmb3IgdXNlIGFzIGRlZmluZWQgYnkgcGFy dGljdWxhciBhcHBsaWNhdGlvbnMgYW5kIGhhcyBubyBhc3NvY2lhdGVkIENPU0UgcHJvY2Vzc2lu ZyBydWxlcy4gVGhhdCBzYXlzIHRoYXQgaXQgYmVsb25ncyBpbiB0aGUgQ0JPUiBXZWIgVG9rZW4g ZHJhZnQsIHdoaWNoIGRlZmluZXMgYXBwbGljYXRpb24gcGF5bG9hZA0KIGZpZWxkcywgcmF0aGVy IHRoYW4gQ09TRSBtZXNzYWdlcyBzcGVjLjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBmaWVsZCBh bHNvIGR1cGxpY2F0ZXMgdGhlIENXVCAmcXVvdDtpc3N1ZWQgYXQmcXVvdDsgdmFsdWUgYXQgPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgt Y2Jvci13ZWItdG9rZW4tMDAjc2VjdGlvbi0zLjEuNiI+DQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10b2tlbi0wMCNzZWN0aW9uLTMu MS42PC9hPi4gVGhlICZxdW90O29wZXJhdGlvbiB0aW1lJnF1b3Q7IHZhbHVlIHNob3VsZCBiZSBk ZWxldGVkIGZyb20gdGhpcyBzcGVjaWZpY2F0aW9uIHRvIGVsaW1pbmF0ZSB0aGlzIHVubmVjZXNz YXJ5IGR1cGxpY2F0aW9uIC0gbm90IGp1c3QgcmVuYW1lZC48bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6bm9uZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM2 NjY2NjYiPuKAlDxicj4NClJlcGx5IHRvIHRoaXMgZW1haWwgZGlyZWN0bHkgb3IgPGEgaHJlZj0i aHR0cHM6Ly9naXRodWIuY29tL2Nvc2Utd2cvY29zZS1pc3N1ZXMvaXNzdWVzLzEzI2lzc3VlY29t bWVudC0xNjk2ODA0MDIiPg0KdmlldyBpdCBvbiBHaXRIdWI8L2E+LjxzcGFuIHN0eWxlPSJib3Jk ZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+PGltZyBib3JkZXI9IjAiIHdp ZHRoPSIxIiBoZWlnaHQ9IjEiIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iY2lkOmltYWdlMDAxLmpw Z0AwMUQxNENBOC41NTRGQjlDMCIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci4iPjwvc3Bh bj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_BY2PR03MB442B12BA81B732F47DC3524F5CA0BY2PR03MB442namprd_-- --_004_BY2PR03MB442B12BA81B732F47DC3524F5CA0BY2PR03MB442namprd_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=332; creation-date="Tue, 12 Jan 2016 03:43:28 GMT"; modification-date="Tue, 12 Jan 2016 03:43:28 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAABAAEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZq/9k= --_004_BY2PR03MB442B12BA81B732F47DC3524F5CA0BY2PR03MB442namprd_-- From nobody Tue Jan 12 06:06:43 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714851B2A22 for ; Tue, 12 Jan 2016 06:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 KgA7dUtkE5xM for ; Tue, 12 Jan 2016 06:06:41 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext1.iad.github.net [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF141B2A1F for ; Tue, 12 Jan 2016 06:06:40 -0800 (PST) Date: Tue, 12 Jan 2016 06:06:39 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1452607599; bh=IQ2uwaLVMML050D7iL8R1ERk4FAnUyU5B5psUsN7vhY=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iuSGvGwmpqXmSV47dAhq2lOFtIA4zIafhsMRmwFI1ldwIdcEWMwAblCvf7xs1DMkg VOmKSolymLfnLmKjzThma0POGBmsxKloBlZcVfldY7uY7098+uX72vnOhWBDdb3WEk D8AEzF81/8jX8ryBgIxtInbCri59FmVyzCQWISCA= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5695086f4b5d3_ece3f95ee2792a018946ae"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jricher X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] Move external_aad to the end of structures using it and make its presence optional (#48) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 14:06:42 -0000 ----==_mimepart_5695086f4b5d3_ece3f95ee2792a018946ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #48. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/48#event-512416038 ----==_mimepart_5695086f4b5d3_ece3f95ee2792a018946ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #48.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_5695086f4b5d3_ece3f95ee2792a018946ae-- From nobody Tue Jan 12 06:07:05 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33AB1B2A1F for ; Tue, 12 Jan 2016 06:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 dLQEWtoys4hi for ; Tue, 12 Jan 2016 06:07:03 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB151B2A28 for ; Tue, 12 Jan 2016 06:06:56 -0800 (PST) Date: Tue, 12 Jan 2016 06:06:55 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1452607615; bh=h03dCFKuaFz8IinwDeNsTEEVgrUcqwTFPi7Evk/3sVI=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Br44GDjNDg26oPhcvwAUiWffMOsEfqNXv0fB/QklYwNpq5VEChjGTxdF0i/fyYUo0 460upDSWbXLvrrC+mCGo7viUZJS+VU/CkAODg1ucN9LZT54sSV1qnF8oWclIKoo8ak 7fy54UL1MrmV4GRPIGUIsZMimguLMveMgkr42zfE= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5695087f65e90_6ca13fa6517672bc203696e"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jricher X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] Should the type of Partial IV be bstr like IV, rather than uint? (#46) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 14:07:05 -0000 ----==_mimepart_5695087f65e90_6ca13fa6517672bc203696e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #46. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/46#event-512416278 ----==_mimepart_5695087f65e90_6ca13fa6517672bc203696e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #46.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_5695087f65e90_6ca13fa6517672bc203696e-- From nobody Tue Jan 12 06:07:17 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24CB1B2A27 for ; Tue, 12 Jan 2016 06:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 S1F9OJu583Xu for ; Tue, 12 Jan 2016 06:07:10 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6C31B2A2A for ; Tue, 12 Jan 2016 06:07:01 -0800 (PST) Date: Tue, 12 Jan 2016 06:07:00 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1452607620; bh=uIKEGiJWRpwtpOXIbCXbeQ92oV8UAoYV4MCyGKu8gxc=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=MRRXPW2grDkq/TO0BGOCjM9txfSSv3OiUX9JomDhejs4z5QLd75tBIk+ol8Cfblbz XNKb/Mugf6IOlO97jKpWDt/sUNj9AWDWCDgVkpY7DClxxoY7eJG0RFrKn55VVgo+Xy J+hrRkdX+ob7olD4PW8FpQ9qpU4PvvJojagg6TpM= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56950884af78a_6eb3fa6517672bc11231f7"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jricher X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] "y > 0" should be "y >= 0" (#45) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 14:07:16 -0000 ----==_mimepart_56950884af78a_6eb3fa6517672bc11231f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #45. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/45#event-512416354 ----==_mimepart_56950884af78a_6eb3fa6517672bc11231f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #45.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_56950884af78a_6eb3fa6517672bc11231f7-- From nobody Tue Jan 12 06:07:22 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF081B2A1F for ; Tue, 12 Jan 2016 06:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 r8qZVM80zxwo for ; Tue, 12 Jan 2016 06:07:18 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext1.iad.github.net [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683501B2A22 for ; Tue, 12 Jan 2016 06:07:15 -0800 (PST) Date: Tue, 12 Jan 2016 06:07:14 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1452607634; bh=DO2NQB6S9G6ZMfxHy0AtmN3tt4hj7TdstqBuO+bQs7E=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gnlcHvCEQoxLIhH0vKAAfEExept0J9Fn429cX8YpS4bw3J2oo7hXlEMWUXHJMLcrb 5Y7P35j5lH95dwSAlIYi7AzSxgYjj/4P4oJ9pYPrvZKX7UJMRUcl+45IQ7JiQk+COu Uk6jGNqjal/qX0/5qvyuMq41Q4ppntGFxtZDb6xw= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56950892bacad_2533fbfc01132c065077e"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jricher X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Additional_inconsistency_betwe?= =?utf-8?b?ZW4g4oCcbm9uZeKAnSBhbmQg4oCcZGlyZWN04oCdIHRlcm1pbm9sb2d5ICgj?= =?utf-8?b?NDQp?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 14:07:21 -0000 ----==_mimepart_56950892bacad_2533fbfc01132c065077e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #44. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/44#event-512416596 ----==_mimepart_56950892bacad_2533fbfc01132c065077e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #44.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_56950892bacad_2533fbfc01132c065077e-- From nobody Tue Jan 12 06:10:30 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F451B2A28 for ; Tue, 12 Jan 2016 06:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 zcgymO2czzov for ; Tue, 12 Jan 2016 06:10:27 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext6.iad.github.net [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FAC41B2A27 for ; Tue, 12 Jan 2016 06:10:27 -0800 (PST) Date: Tue, 12 Jan 2016 06:10:26 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1452607826; bh=zMQwUl3TmTqKutYPQzXu2a1ZABbyELNUhzcTCDe1ucU=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=hKlZRKw857uyBo9EyxxOJziA4AF8I1tmdjIqmbO9iIdMF86jifcEVP0WcNFWvf1Ao /G4wZYUzzsWjEfdadcUlw9Zp1qvivMsliL9GoseD49hpISECFNnvjDQFw1j7ZXjEFC JOsXn7/9m2jTU4wrxUU+SdEo5M+d0aQKWQtkj0V4= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_569509528f172_6a73fa6517672bc2079567"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jricher X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] Add reference documenting reasons for odd CCM nonce lengths (#33) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 14:10:28 -0000 ----==_mimepart_569509528f172_6a73fa6517672bc2079567 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #33. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/33#event-512419864 ----==_mimepart_569509528f172_6a73fa6517672bc2079567 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #33.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_569509528f172_6a73fa6517672bc2079567-- From nobody Tue Jan 12 06:11:27 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668371B2A2C for ; Tue, 12 Jan 2016 06:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 YiGWW8r1UI7x for ; Tue, 12 Jan 2016 06:11:15 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext5.iad.github.net [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D041B2A27 for ; Tue, 12 Jan 2016 06:11:15 -0800 (PST) Date: Tue, 12 Jan 2016 06:11:14 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1452607874; bh=DWrkDSmEPpEfkIDBYBJ0JFp3hMd5f0S9e72bDqZuucI=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=uURiXyF0Dntrl5BQEWM2X7A+bB3Mlj/FhwMZJHcIMuZ9aX7hTgF2Xkhl13HsWeuGk QyGguMUuGgT2omQYvtasP43Aed6ZfU6PJHObkqcgO0w7peKazl5YrHXsfV17jWT2+X 3lnPwIwXZNxUjmKY1ejbM2PBjZNBl9R3SmwoFdLM= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56950982e32d8_56bb3f973b0ef29c1363982"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jricher X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Retain_text_marked_=E2=80=9CTe?= =?utf-8?q?xt_from_here_to_start_of_next_section_to_be_removed=E2=80=9D_?= =?utf-8?b?KCMxMSk=?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 14:11:26 -0000 ----==_mimepart_56950982e32d8_56bb3f973b0ef29c1363982 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #11. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/11#event-512420567 ----==_mimepart_56950982e32d8_56bb3f973b0ef29c1363982 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #11.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_56950982e32d8_56bb3f973b0ef29c1363982-- From nobody Tue Jan 12 10:44:18 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707E11A1BD7 for ; Tue, 12 Jan 2016 10:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 ECm_7zhXvomo for ; Tue, 12 Jan 2016 10:44:13 -0800 (PST) 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 098441A1BB8 for ; Tue, 12 Jan 2016 10:44:12 -0800 (PST) Received: from hebrews (unknown [50.141.111.95]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 6D45038F04; Tue, 12 Jan 2016 10:44:09 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" References: <00b401d14a72$eccb5210$c661f630$@augustcellars.com> <040d01d14ccd$30bb4140$9231c3c0$@augustcellars.com> In-Reply-To: Date: Tue, 12 Jan 2016 10:41:30 -0800 Message-ID: <052701d14d68$dc395f20$94ac1d60$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0528_01D14D25.CE31E480" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQHnVbEEf4RRBeXSolS/kzUPbuZGtgLLHPuuAcn9m6IDIlW9kgKxNstTAfBWRsGeaG4BEA== Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] =?utf-8?q?=5Bcose-issues=5D_Move_=E2=80=9Ccreation_time?= =?utf-8?b?4oCdIHZhbHVlIHRvIHRoZSBwYXlsb2FkICgjMTMp?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 18:44:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0528_01D14D25.CE31E480 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0529_01D14D25.CE31E480" ------=_NextPart_001_0529_01D14D25.CE31E480 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I cannot agree with your =E2=80=9Dbright line test=E2=80=9D. I do not = believe that this test makes any sense and I do not believe that you = have really thought the implications of this rule through. =20 1. If this is really the rule to be applied then it makes sense to = say that this should be applied to all of the header fields, but that is = not what you are doing. To say that cryptographic rules are required = would imply that you should be arguing that the =E2=80=9Ccontent = type=E2=80=9D header field should also be eliminated. There are no = cryptographic rules that are applied to this field either. You have not = been arguing for this field to be removed.=20 2. The concept that an application could define a header parameter = but this document cannot define the spec means that this is not a rule = for the registry, but a rule for the specification. However, the it = makes complete sense for this specification to define those header = fields that a significant portion of the community believes that might = be useful for applications so that they are in a single specification = and likely to be provided by general libraries rather than being in a = secondary specification that everybody will need to find and see if it = is implemented. 3. As the specification outlines, there are cases in this document = where this field can be used. To wit counter signatures. There are a = number of other cases where this also makes sense that are not covered = in this document because there does not seem to be any reason to cover = them as they are deployment specific. But this could include gateway = and proxy signing. List server signing (CoAP has this concept but calls = it something different.) Additionally, the time that a statement is = asserted at and the time that the cryptographic operation is done may be = different even for a CWT so that if this field was used, it might not = agree with the content of the CWT. 4. The concept of synchronized clocks is not something that should = be dismissed out of hand. If you look at the sensor in my = aunt=E2=80=99s backyard, it is a relatively large sensor and has a solar = panel to power the battery. This means that it could easily have a = clock configured and potentially even be synchronized. The size of a = sensor varies a lot so that some will be able to have time and some will = not. =20 Jim =20 =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Monday, January 11, 2016 7:43 PM To: Jim Schaad Cc: cose@ietf.org Subject: RE: [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D value to = the payload (#13) =20 Fair enough. But there=E2=80=99s nothing stopping the sensor = application from defining a header parameter that does exactly what it = needs to do, registering it, and using. The =E2=80=9Ccreation = time=E2=80=9D parameter implies synchronized clocks, which probably = takes it out of applicability in the sensor space already. There are = lots of good application-specific choices. =20 The bright line test for me that says that this header parameter = doesn=E2=80=99t belong in the crypto spec is that there are no = cryptographic processing rules for it. That says that it=E2=80=99s = application data =E2=80=93 not crypto data. And as such, it should be = defined by applications =E2=80=93 not the crypto spec. =20 Please remove this parameter. =20 -- Mike =20 From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Monday, January 11, 2016 4:07 PM To: Mike Jones > Cc: cose@ietf.org =20 Subject: RE: [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D value to = the payload (#13) =20 I will point out that this is designed to wrap things other than CWT. = If you are wrapping a sensor reading then there is not a CWT involved at = that point. =20 Jim =20 =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Monday, January 11, 2016 12:28 PM To: Jim Schaad > Cc: cose@ietf.org =20 Subject: RE: [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D value to = the payload (#13) =20 I have now. This still feels like unnecessary duplication of the CBOR = Web Token (CWT) =E2=80=9Ciat=E2=80=9D (issued at) = claim to me, but I=E2=80=99m curious what others think. =20 -- Mike =20 From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Friday, January 8, 2016 4:16 PM To: Mike Jones > Cc: cose@ietf.org =20 Subject: RE: [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D value to = the payload (#13) =20 Did you read the change in the text that was made at the same time? = It states that =E2=80=9CThe field is primarily intended to be to be used = for countersignatures, however it can additionally be used for replay = detection as well.=E2=80=9D It is not possible to put the time field in = the content for a countersignature as there is no customizable content = in that case. =20 =20 =20 From: Mike Jones [mailto:notifications@github.com]=20 Sent: Thursday, January 07, 2016 6:34 AM To: cose-wg/cose-issues > Cc: Jim Schaad > Subject: Re: [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D value to = the payload (#13) =20 Changing the name does not address the core issue that this field is = solely for use as defined by particular applications and has no = associated COSE processing rules. That says that it belongs in the CBOR = Web Token draft, which defines application payload fields, rather than = COSE messages spec. This field also duplicates the CWT "issued at" value at = https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#sect= ion-3.1.6. The "operation time" value should be deleted from this = specification to eliminate this unnecessary duplication - not just = renamed. =E2=80=94 Reply to this email directly or view it on GitHub = = . ------=_NextPart_001_0529_01D14D25.CE31E480 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I cannot agree with your =E2=80=9Dbright line test=E2=80=9D.=C2=A0 I do = not believe that this test makes any sense and I do not believe that you = have really thought the implications of this rule = through.

 

1.      = =C2=A0If this is really the rule to be applied then it makes sense to = say that this should be applied to all of the header fields, but that is = not what you are doing.=C2=A0 To say that cryptographic rules are = required would imply that you should be arguing that the = =E2=80=9Ccontent type=E2=80=9D header field should also be = eliminated.=C2=A0 There are no cryptographic rules that are applied to = this field either.=C2=A0 You have not been arguing for this field to be = removed.

2.      = The concept that an application could define a header parameter but = this document cannot define the spec means that this is not a rule for = the registry, but a rule for the specification.=C2=A0 However, the it = makes complete sense for this specification to define those header = fields that a significant portion of the community believes that might = be useful for applications so that they are in a single specification = and likely to be provided by general libraries rather than being in a = secondary specification that everybody will need to find and see if it = is implemented.

3.      = As the specification outlines, there are cases in this document where = this field can be used.=C2=A0 To wit counter signatures.=C2=A0 There are = a number of other cases where this also makes sense that are not covered = in this document because there does not seem to be any reason to cover = them as they are deployment specific.=C2=A0 But this could include = gateway and proxy signing.=C2=A0 List server signing (CoAP has this = concept but calls it something different.) Additionally, the time that a = statement is asserted at and the time that the cryptographic operation = is done may be different even for a CWT so that if this field was used, = it might not agree with the content of the CWT.

4.      = The concept of synchronized clocks is not something that should be = dismissed out of hand.=C2=A0 If you look at the sensor in my = aunt=E2=80=99s backyard, it is a relatively large sensor and has a solar = panel to power the battery.=C2=A0 This means that it could easily have a = clock configured and potentially even be synchronized.=C2=A0 The size of = a sensor varies a lot so that some will be able to have time and some = will not.

 

Jim

 

 

From:<= /b> = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Monday, = January 11, 2016 7:43 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = cose@ietf.org
Subject: RE: [cose-issues] Move = =E2=80=9Ccreation time=E2=80=9D value to the payload = (#13)

 

Fair enough.  But there=E2=80=99s nothing stopping the sensor = application from defining a header parameter that does exactly what it needs to do, registering it, and = using.  The =E2=80=9Ccreation time=E2=80=9D parameter implies = synchronized clocks, which probably takes it out of applicability in the = sensor space already.  There are lots of good application-specific = choices.

 

The bright line test for me that says that this header parameter = doesn=E2=80=99t belong in the crypto spec is that there are no = cryptographic processing rules for it.  That says that it=E2=80=99s = application data =E2=80=93 not crypto data.  And as such, it should = be defined by applications =E2=80=93 not the crypto = spec.

 

Please remove this parameter.

 

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

 

From:<= /b> = Jim Schaad [mailto:ietf@augustcellars.com]=
Sent: Monday, January 11, 2016 4:07 PM
To: Mike = Jones <Michael.Jones@microsoft.com>
Cc: cose@ietf.org
Subject: RE: = [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D value to the payload = (#13)

 

I will point out that this is designed to wrap things other than = CWT.  If you are wrapping a sensor reading then there is not a CWT = involved at that point.

 

Jim

 

 

From:<= /b> = Mike Jones [mailto:Michael.Jones@microsof= t.com]
Sent: Monday, January 11, 2016 12:28 = PM
To: Jim Schaad <ietf@augustcellars.com>
= Cc: cose@ietf.org
Subject: RE: = [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D value to the payload = (#13)

 

I have now.  This still feels like unnecessary duplication of the = CBOR Web Token (CWT) =E2=80=9Ciat=E2=80=9D (issued = at) claim to me, but I=E2=80=99m curious what others = think.

 

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

 

From:<= /b> = Jim Schaad [mailto:ietf@augustcellars.com]=
Sent: Friday, January 8, 2016 4:16 PM
To: Mike = Jones <Michael.Jones@microsoft.com>
Cc: cose@ietf.org
Subject: RE: = [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D value to the payload = (#13)

 

Did you read the change in the text that was made at the same = time?    It states that =E2=80=9CThe field is primarily = intended to be to be used for countersignatures, however it can = additionally be used for replay detection as well.=E2=80=9D  It is = not possible to put the time field in the content for a countersignature = as there is no customizable content in that = case.

 

 

 

From:<= /b> = Mike Jones [mailto:notifications@github.com<= /a>]
Sent: Thursday, January 07, 2016 6:34 AM
To: = cose-wg/cose-issues <cose-issues@noreply.github= .com>
Cc: Jim Schaad <ietf@augustcellars.com>
= Subject: Re: [cose-issues] Move =E2=80=9Ccreation time=E2=80=9D = value to the payload (#13)

 

Changing the name does not = address the core issue that this field is solely for use as defined by = particular applications and has no associated COSE processing rules. = That says that it belongs in the CBOR Web Token draft, which defines = application payload fields, rather than COSE messages = spec.

This field also duplicates the CWT "issued = at" value at https://tools.ietf.org/html/draft-wahlstroem-oauth-cbo= r-web-token-00#section-3.1.6. The "operation time" value = should be deleted from this specification to eliminate this unnecessary = duplication - not just renamed.

=E2=80=94
Reply to this email directly or view it on GitHub.3D"Image

------=_NextPart_001_0529_01D14D25.CE31E480-- ------=_NextPart_000_0528_01D14D25.CE31E480 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAABAAEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZq/9k= ------=_NextPart_000_0528_01D14D25.CE31E480-- From nobody Wed Jan 13 20:26:19 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672471A6F60 for ; Wed, 13 Jan 2016 20:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 T1fLjb5btwwm for ; Wed, 13 Jan 2016 20:26:17 -0800 (PST) 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 06A7C1A6F05 for ; Wed, 13 Jan 2016 20:26:16 -0800 (PST) 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: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 60DEE2CA0A; Wed, 13 Jan 2016 20:26:16 -0800 (PST) From: "Jim Schaad" To: Date: Wed, 13 Jan 2016 20:23:40 -0800 Message-ID: <021801d14e83$58d1c5c0$0a755140$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AdFOgH4yRUypsA5ZRuy/QyLeWSCneA== Archived-At: Cc: 'Hannes Tschofenig' Subject: [COSE] Issue - Change the definition of label X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 04:26:18 -0000 In a piece of mail, Hannes raised the following issue. Additionally, I also don't like the idea of having a label be either an integer or a string. Why cannot we just use integers? This sounds like introducing options for no good reasons that just increase the implementation complexity If we make this change, I would have it affect more than just label, it would affect all of the registries. Currently the definition of label is label = uint / sint / tstring That is a label can be an unsigned integer, a signed integer or a text string. I added the string to the definition of label in order to expand the size of the registration space for two byte identifiers. If we are willing to accept the decrease of the availability of short labels then we can easily remove tstring from the definition. Part of the reason that is given by Hannes was the idea that this increases the complexity for little gain. The amount of complexity introduced is going to depend for a large part on how the CBOR library is implemented and the willingness of the programmer to make potentially incorrect assumptions. (I am currently really guilty of doing this.) A correct implementation would check both the type of the field and the value of the field. An incorrect implementation would fold the two types together and just check the value of the field. This means that there is already a requirement to have two case statements (or a small number of if statements) in order to check if the value is correct. Going from two to three does not really add a great deal of complexity as the code for the string case would be the same for short strings, it only becomes more complicated if the strings are sufficiently long to require a string compare rather than a cast followed by an integer compare. While I have allowed for the registration space, I have very carefully avoided doing any registrations in the string portion of the registry. I have however used this range extensively during code development for dealing with items which I have not yet assigned code points to. (I.e. the use of ES384 rather than the -35 that I just recently assigned to it). People have expressed concern about the small registration space, this is a place where we are expanding it, but at some additional complexity. Which of the two items is more important? I would like to resolve this by the end of next week. Jim From nobody Wed Jan 13 20:49:56 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA8A1A8BB4 for ; Wed, 13 Jan 2016 20:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 BLJhdFP0lKwJ for ; Wed, 13 Jan 2016 20:49:54 -0800 (PST) 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 4E9931A8BB3 for ; Wed, 13 Jan 2016 20:49:54 -0800 (PST) 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: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id AF55638EEE; Wed, 13 Jan 2016 20:49:53 -0800 (PST) From: "Jim Schaad" To: Date: Wed, 13 Jan 2016 20:47:17 -0800 Message-ID: <022401d14e86$a59c8ea0$f0d5abe0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AdFOhFd3Hva3GRCvTU6tVy7n3ZU2Cw== Archived-At: Cc: 'Francesca Palombini' Subject: [COSE] Issue - add the value type 'bstr' to counter signature X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 04:49:55 -0000 At this time, I would like to discuss the details of what this means rather than should we do this. I will bring up the issue of yes/no on doing this after this has seen some discussion. (Doing this depends on issue #51 in the database.) How this works need to have some explanation. What is the algorithm that is to be used for generating the 'to be signed' bytes. I can see two options right off the bat and there are probably more. 1. The following are to be considered to be the same [h'', {}, h'signature'] and h'signature' are interchangeable. This means that there are some implicit fields that need to be described for the signature process. It also implies that there is a mechanical conversion between these two forms of the counter signature data. 2. There is a new CDDL structure to be defined for computing the counter signature which has a more restricted set of data. Specifically this would create a Sig_structure of Sig_structure = [ context: "some context string", body_protected : bstr, external_aad : bstr, payload : bstr ] This omits the same sign_protected field that is absent for the Sign0 signature processing. The description in github correctly notes that there is an issue of needing to have an implied algorithm. The other question that needs to be address is how this also implies a key to be used. Is there an assumption that needs to be stated that the core message and the countersignature are going to be created by the same key context? Jim From nobody Thu Jan 14 06:55:59 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6639A1B353D for ; Thu, 14 Jan 2016 06:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 WxsQKkzAooiH for ; Thu, 14 Jan 2016 06:55:57 -0800 (PST) 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 7F9571B32DF for ; Thu, 14 Jan 2016 06:55:56 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-04-5697b6fa26b3 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 88.30.02707.AF6B7965; Thu, 14 Jan 2016 15:55:54 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.147]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Thu, 14 Jan 2016 15:55:54 +0100 From: Francesca Palombini To: Jim Schaad , "cose@ietf.org" Thread-Topic: Issue - add the value type 'bstr' to counter signature Thread-Index: AdFOhFd3Hva3GRCvTU6tVy7n3ZU2CwAVNnGA Date: Thu, 14 Jan 2016 14:55:53 +0000 Message-ID: References: <022401d14e86$a59c8ea0$f0d5abe0$@augustcellars.com> In-Reply-To: <022401d14e86$a59c8ea0$f0d5abe0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7k+6vbdPDDBbP0rKYtnUqq8Xq6d/Z HJg8Ns6ZzuaxZMlPpgCmKC6blNSczLLUIn27BK6MRXO3MhbcFK2YsmwhYwNjj2AXIyeHhICJ xIPuvcwQtpjEhXvr2UBsIYHDjBLXt1d2MXIB2UsYJVadvQFWxCZgI3Hh4XtWEFtEwENi1+5P YHFhAWeJfT8eMkHEXSQ27Z/NDmEbSTy4+pwRxGYRUJV4enETWC+vgK/E1pbvTBDL7CXu9B0F szkFHCSONv4G62UEOuj7qTVgcWYBcYlbT+YzQRwqILFkz3moo0UlXj7+xwphK0p8fLWPEaJe R2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxhFi1OLk3LTjYz0 Uosyk4uL8/P08lJLNjEC4+Tglt8GOxhfPnc8xCjAwajEw2vAPz1MiDWxrLgy9xCjBAezkgiv 9iqgEG9KYmVValF+fFFpTmrxIUZpDhYlcd4kmcYwIYH0xJLU7NTUgtQimCwTB6dUA2P1rMSr e4Uzi0uunNCdsqVq7ZkamTmvTh84uvD7nLRv+/7PcvP97/jmzq2PZmEXVjb79mcrLlz2dvlT 7ytpX4unF8mr35r+5Nvptbn/P5lY2+SqvPw9L3PtcXsT+VlnxGKV//NHfWxwEyx5nfjlePaP BwcFNC5Gz31ZoZ+YmjtDeWfAgfKVH9j/KbEUZyQaajEXFScCAC2BWyCPAgAA Archived-At: Subject: Re: [COSE] Issue - add the value type 'bstr' to counter signature X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 14:55:58 -0000 Hi Jim, We suggested this modification with something similar to your point 2 in mi= nd: a new CDDL structure should be defined for computing the counter signat= ure with a more restricted set of data. This would be the equivalent of the= COSE_Sign1 for the counter signature. You could even have a new label for = this "shorter counter signature" and instead of having: Generic_Headers =3D ( ... ? 7 =3D> COSE_Signature / bstr, ; Counter signature ... ) As it was suggested in the github, we could have: Generic_Headers =3D ( ... ? 7 =3D> COSE_Signature, ; Counter signature ? X =3D> bstr, ; "Shorter" counter signature ... ) In order to make the distinction easier, and to know what Sig_structure to = use to compute the counter signature. And to answer your question, yes, in our proposal the algorithm and the key= to use are in fact defined in the same security context as the algorithm a= nd key for the core message. Francesca -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: den 14 januari 2016 05:47 To: cose@ietf.org Cc: Francesca Palombini Subject: Issue - add the value type 'bstr' to counter signature At this time, I would like to discuss the details of what this means rather= than should we do this. I will bring up the issue of yes/no on doing this= after this has seen some discussion. (Doing this depends on issue #51 in = the database.) How this works need to have some explanation. What is the algorithm that is to be used for generating the 'to be signed' bytes. I can see two options right off the bat and there are probably more= . 1. The following are to be considered to be the same [h'', {}, h'signature= '] and h'signature' are interchangeable. This means that there are some im= plicit fields that need to be described for the signature process. It also= implies that there is a mechanical conversion between these two forms of t= he counter signature data. 2. There is a new CDDL structure to be defined for computing the counter s= ignature which has a more restricted set of data. Specifically this would = create a Sig_structure of Sig_structure =3D [ context: "some context string", body_protected : bstr, external_aad : bstr, payload : bstr ] This omits the same sign_protected field that is absent for the Sign0 signa= ture processing. The description in github correctly notes that there is an issue of needing= to have an implied algorithm. The other question that needs to be address= is how this also implies a key to be used. Is there an assumption that ne= eds to be stated that the core message and the countersignature are going t= o be created by the same key context? Jim From nobody Thu Jan 14 10:38:36 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAA21A8A86 for ; Thu, 14 Jan 2016 10:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 sbu_Y5WzQWkg for ; Thu, 14 Jan 2016 10:38:34 -0800 (PST) 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 06F931A8A7A for ; Thu, 14 Jan 2016 10:38:33 -0800 (PST) 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: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 099432CA1B; Thu, 14 Jan 2016 10:38:32 -0800 (PST) From: "Jim Schaad" To: "'Francesca Palombini'" , References: <022401d14e86$a59c8ea0$f0d5abe0$@augustcellars.com> In-Reply-To: Date: Thu, 14 Jan 2016 10:35:57 -0800 Message-ID: <02b801d14efa$68d89530$3a89bf90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQMOGAAx83HJUhDx1zgdaUJE0bwr/wMLPHyCnGlqhQA= Archived-At: Subject: Re: [COSE] Issue - add the value type 'bstr' to counter signature X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 18:38:35 -0000 > -----Original Message----- > From: Francesca Palombini [mailto:francesca.palombini@ericsson.com] > Sent: Thursday, January 14, 2016 6:56 AM > To: Jim Schaad ; cose@ietf.org > Subject: RE: Issue - add the value type 'bstr' to counter signature > > Hi Jim, > > We suggested this modification with something similar to your point 2 in mind: a > new CDDL structure should be defined for computing the counter signature with > a more restricted set of data. This would be the equivalent of the COSE_Sign1 > for the counter signature. You could even have a new label for this "shorter > counter signature" and instead of having: > > Generic_Headers = ( > ... > ? 7 => COSE_Signature / bstr, ; Counter signature ... > ) > > As it was suggested in the github, we could have: > > Generic_Headers = ( > ... > ? 7 => COSE_Signature, ; Counter signature ? X => bstr, ; "Shorter" counter > signature ... > ) > > In order to make the distinction easier, and to know what Sig_structure to use to > compute the counter signature. > And to answer your question, yes, in our proposal the algorithm and the key to > use are in fact defined in the same security context as the algorithm and key for > the core message. Well done, this is precisely where I wanted to go in the even that a different Sig_structure was to be used in computing the value. Let's wait a couple of days to see if anyone else wants to weigh in on the this issue and move to the question of implicit algorithms then. Jim > > > Francesca > > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: den 14 januari 2016 05:47 > To: cose@ietf.org > Cc: Francesca Palombini > Subject: Issue - add the value type 'bstr' to counter signature > > At this time, I would like to discuss the details of what this means rather than > should we do this. I will bring up the issue of yes/no on doing this after this has > seen some discussion. (Doing this depends on issue #51 in the database.) > > How this works need to have some explanation. > > What is the algorithm that is to be used for generating the 'to be signed' > bytes. I can see two options right off the bat and there are probably more. > > 1. The following are to be considered to be the same [h'', {}, h'signature'] and > h'signature' are interchangeable. This means that there are some implicit fields > that need to be described for the signature process. It also implies that there is > a mechanical conversion between these two forms of the counter signature > data. > > 2. There is a new CDDL structure to be defined for computing the counter > signature which has a more restricted set of data. Specifically this would create > a Sig_structure of > > Sig_structure = [ > context: "some context string", > body_protected : bstr, > external_aad : bstr, > payload : bstr > ] > > This omits the same sign_protected field that is absent for the Sign0 signature > processing. > > The description in github correctly notes that there is an issue of needing to have > an implied algorithm. The other question that needs to be address is how this > also implies a key to be used. Is there an assumption that needs to be stated > that the core message and the countersignature are going to be created by the > same key context? > > Jim From nobody Thu Jan 14 22:11:12 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F2B1AD2AF for ; Thu, 14 Jan 2016 22:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 MgvRpzrpBPhP for ; Thu, 14 Jan 2016 22:11:10 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14DF1A90F7 for ; Thu, 14 Jan 2016 22:11:09 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id q19so259425680qke.3 for ; Thu, 14 Jan 2016 22:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ueaSuD1u7pnRk9ShJm+MTEjferzUdo6Rt2+pv/5uxP0=; b=BaWIrdViutj5bHarCMmMIBxZPOh5/hfVtq6glAnbBV6PNyStABzT/ihvuLEOF4oX+G R5m6fHlhWLslkZiFu7LYiftidOXY4if+a9s3cY5PtEz6wUaaj4Iiwxw+qkEH8UbrYPH1 czP0p+h8eOFN1CqMuTuo1hY5Ut6BnKVM+HksrTh9pkbKQVs+trnwQUr7HIZFkiBVA5Sa CRKPbekP8kb7n9DX+vHjCR9UlfM+r3f4nr5VGkKOpGJiO3GJ4P41LhoqDJTD5cYEiCFd w0JE9dwIYTRS3UqaZqlC4hlTxIYNBu+SzRx16rrk48i95xu9uWrX5c8sM2mqDYUfPcTo NOJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ueaSuD1u7pnRk9ShJm+MTEjferzUdo6Rt2+pv/5uxP0=; b=f5gd8/KF+/8I2EhsKtsT4vTOgMlMp85kv7LdQmNn14i+VGLWekB6NCW1nRnUc/Evhx 9QaA0QoSZRYGgBGYKOvdc77uTfdRZgbBfrPRLnpbPcIUqk3w2kETqg9QMOt8NMmZX3/Z U6rEsiVjf91CLL/6QLcSKjQbDDbABx4uhNu86+GVIWpJYGYXaDpop3JG85Vg519WQmcc C6c3VgYg5H5KcyPv8eA92SVi0ddpfAEZki8FA9vU4L7W3mP9X+7SoUrckTTG3+cornZ4 6hsi49iXmNUAa6Oji6YNabQWs9Unkqv4iKenR+Ur0lDQV7elKHtOxKOR23NCK6qqQE6Q 7jEQ== X-Gm-Message-State: ALoCoQkphSwrvvuiB0aoOhontCABHZr7BW2Z5DzldzYJsee1FoqjqPveFFwOrtA4DhU2/eMNylFULMHGu7V+Qhc55HgefIy7hg== MIME-Version: 1.0 X-Received: by 10.55.77.216 with SMTP id a207mr10780647qkb.80.1452838268740; Thu, 14 Jan 2016 22:11:08 -0800 (PST) Received: by 10.55.179.1 with HTTP; Thu, 14 Jan 2016 22:11:08 -0800 (PST) In-Reply-To: <021801d14e83$58d1c5c0$0a755140$@augustcellars.com> References: <021801d14e83$58d1c5c0$0a755140$@augustcellars.com> Date: Fri, 15 Jan 2016 07:11:08 +0100 Message-ID: From: Samuel Erdtman To: Jim Schaad Content-Type: multipart/alternative; boundary=001a114a7d98ecbe4e05295944a6 Archived-At: Cc: Hannes Tschofenig , cose Subject: Re: [COSE] Issue - Change the definition of label X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 06:11:12 -0000 --001a114a7d98ecbe4e05295944a6 Content-Type: text/plain; charset=UTF-8 Hi Jim, I like the idea of just having way to do thing i.e. only allow labels to be one of the suggested datatypes uint / sint / tstring. You say that doing so would limit the number of two byte identifiers to use (clearly). To make an informed decision I think it would be good to know how many two byte identifier we loos by selecting one of the datatypes for labels. (The answer might be obvious but with my limited CBOR skills I cannot see it). Best regards //Samuel On Thu, Jan 14, 2016 at 5:23 AM, Jim Schaad wrote: > In a piece of mail, Hannes raised the following issue. > > Additionally, I also don't like the idea of having a label be either an > integer or a string. Why cannot we just use integers? This sounds like > introducing options for no good reasons that just increase the > implementation complexity > > If we make this change, I would have it affect more than just label, it > would affect all of the registries. > > Currently the definition of label is > > label = uint / sint / tstring > > That is a label can be an unsigned integer, a signed integer or a text > string. I added the string to the definition of label in order to expand > the size of the registration space for two byte identifiers. If we are > willing to accept the decrease of the availability of short labels then we > can easily remove tstring from the definition. > > Part of the reason that is given by Hannes was the idea that this increases > the complexity for little gain. The amount of complexity introduced is > going to depend for a large part on how the CBOR library is implemented and > the willingness of the programmer to make potentially incorrect > assumptions. > (I am currently really guilty of doing this.) > > A correct implementation would check both the type of the field and the > value of the field. An incorrect implementation would fold the two types > together and just check the value of the field. This means that there is > already a requirement to have two case statements (or a small number of if > statements) in order to check if the value is correct. Going from two to > three does not really add a great deal of complexity as the code for the > string case would be the same for short strings, it only becomes more > complicated if the strings are sufficiently long to require a string > compare > rather than a cast followed by an integer compare. > > While I have allowed for the registration space, I have very carefully > avoided doing any registrations in the string portion of the registry. I > have however used this range extensively during code development for > dealing > with items which I have not yet assigned code points to. (I.e. the use of > ES384 rather than the -35 that I just recently assigned to it). > > People have expressed concern about the small registration space, this is a > place where we are expanding it, but at some additional complexity. Which > of the two items is more important? > > I would like to resolve this by the end of next week. > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --001a114a7d98ecbe4e05295944a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jim,

I like the idea of just having = way to do thing i.e. only allow labels to be one of the suggested datatypes= =C2=A0uint / sint / tstring.
<= div>
You say that doing so would limit the number of two byte i= dentifiers to use (clearly). To make an informed=C2=A0decision=C2=A0I think= it would be=C2=A0good to know how many two byte identifier we loos by sele= cting one of the datatypes for labels. (The answer might be obvious but wit= h my limited CBOR skills I cannot see it).

Be= st regards
//Samuel




On Thu, Jan 14, 2016 at 5:23 AM, Jim Schaad <ietf@augustcellars.com> wrote:
In a piece of mail, Hannes raised the following issue.

Additionally, I also don't like the idea of having a label be either an=
integer or a string. Why cannot we just use integers? This sounds like
introducing options for no good reasons that just increase the
implementation complexity

If we make this change, I would have it affect more than just label, it
would affect all of the registries.

Currently the definition of label is

label =3D uint / sint / tstring

That is a label can be an unsigned integer, a signed integer or a text
string.=C2=A0 =C2=A0I added the string to the definition of label in order = to expand
the size of the registration space for two byte identifiers.=C2=A0 If we ar= e
willing to accept the decrease of the availability of short labels then we<= br> can easily remove tstring from the definition.

Part of the reason that is given by Hannes was the idea that this increases=
the complexity for little gain.=C2=A0 The amount of complexity introduced i= s
going to depend for a large part on how the CBOR library is implemented and=
the willingness of the programmer to make potentially incorrect assumptions= .
(I am currently really guilty of doing this.)

A correct implementation would check both the type of the field and the
value of the field.=C2=A0 An incorrect implementation would fold the two ty= pes
together and just check the value of the field.=C2=A0 This means that there= is
already a requirement to have two case statements (or a small number of if<= br> statements) in order to check if the value is correct.=C2=A0 Going from two= to
three does not really add a great deal of complexity as the code for the string case would be the same for short strings, it only becomes more
complicated if the strings are sufficiently long to require a string compar= e
rather than a cast followed by an integer compare.

While I have allowed for the registration space, I have very carefully
avoided doing any registrations in the string portion of the registry.=C2= =A0 I
have however used this range extensively during code development for dealin= g
with items which I have not yet assigned code points to.=C2=A0 (I.e. the us= e of
ES384 rather than the -35 that I just recently assigned to it).

People have expressed concern about the small registration space, this is a=
place where we are expanding it, but at some additional complexity.=C2=A0 W= hich
of the two items is more important?

I would like to resolve this by the end of next week.

Jim


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

--001a114a7d98ecbe4e05295944a6-- From nobody Thu Jan 14 22:16:35 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED801B29AE for ; Thu, 14 Jan 2016 22:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 uzbuzPrLR6gC for ; Thu, 14 Jan 2016 22:16:32 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 11F0B1B29AD for ; Thu, 14 Jan 2016 22:16:32 -0800 (PST) Received: by mail-qg0-x22e.google.com with SMTP id 6so422636777qgy.1 for ; Thu, 14 Jan 2016 22:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vogjY4HGkyVcJbWD3ynIfqwCdO4dxwuM/+55a5lTa4o=; b=DdMGrm9yQgxUcI32ZgDMqAreHJAsGaFgh8e7JlV1DuvpytD5VIa12r4pQuVyr35Q0c wZjNR2tNDTVvGN6RIeDQdWTElDfN2u8m6IKwqeFiKmPYqO+8x8yQI2BMDzAJVeWdvsZ6 l3BtVsFyamFZgEkgSEJ+Z7re1ySeCea6EyxyKkho2hF88KlY1a25tT9ZJTFJNFkGJxe0 7KI+TMbvqsHk+4ZNdcMLH0lxft6SrFvKhh/CFOlf9lRNRhxfcLuNwBOZDGl1kh3S2PXO QooYmvNvm1Qf6K6WNwuWi9QIgoWn2DO9F6EGRFZWlq8y0FSffgGS6DhpVG2DvgHc+vMw hj8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vogjY4HGkyVcJbWD3ynIfqwCdO4dxwuM/+55a5lTa4o=; b=QyjYfuzxv5Vnui3pw2wzAIBaa8pYEK1WZvuZAZngXfymRBlyI7Xm7PO3HlP8MvAsJU xjckbBwSCxaQL+3M2fOQvBGczx2Nvr/sxdyJ3NsQa/3c1JWIl2KMYw4GTow4op2SRLAt F3p178S9C5fP/IMAbQpQiQfgs1YEoK6WpwDD2JuzRsJCSlx+544SBzvFHpS5WiItV9t3 fo5R3PGzoHOXyHnGJtPGRcU78ZxrOKEZ5ZzSZTgE+F1p5r2wo5Ibx9FZ/qI4qh3pwd7/ nKZcWyV9eVAJ9gTG895I/apiETpKpkbuLIeag5u6sPwJZ7mwXQx9+fHllQ+NamAkNB/k Y86Q== X-Gm-Message-State: ALoCoQleQRUeIXBOTfe6i+AKoZG9FO2GKuoKmdd1CLBmAoYcQASeefi4ZIMcddJJL0LAnGNSqHaFxz5JsRGBRzYnx9wbcMsBQA== MIME-Version: 1.0 X-Received: by 10.140.161.9 with SMTP id h9mr11682714qhh.82.1452838591248; Thu, 14 Jan 2016 22:16:31 -0800 (PST) Received: by 10.55.179.1 with HTTP; Thu, 14 Jan 2016 22:16:31 -0800 (PST) In-Reply-To: References: <021801d14e83$58d1c5c0$0a755140$@augustcellars.com> Date: Fri, 15 Jan 2016 07:16:31 +0100 Message-ID: From: Samuel Erdtman To: Jim Schaad Content-Type: multipart/alternative; boundary=001a113a731825ddc205295958ae Archived-At: Cc: Hannes Tschofenig , cose Subject: Re: [COSE] Issue - Change the definition of label X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 06:16:34 -0000 --001a113a731825ddc205295958ae Content-Type: text/plain; charset=UTF-8 I found the answer to my question in an earlier mail from you Jim "If we allow only integers to be used, then there is a maximum of 255 + 255 values that can be encoded as a two bytes (a portion of those are actually encoded as single bytes). If we add the text string to that then we allow for an additional 180 points where we can have a single byte encoding be added. (Respecting the UTF8-ness of the field shrinks it slightly.)" With this input I think the added value of string label is not worth the added code complexity. Best Regards //Samuel On Fri, Jan 15, 2016 at 7:11 AM, Samuel Erdtman wrote: > Hi Jim, > > I like the idea of just having way to do thing i.e. only allow labels to > be one of the suggested datatypes uint / sint / tstring. > > You say that doing so would limit the number of two byte identifiers to > use (clearly). To make an informed decision I think it would be good to > know how many two byte identifier we loos by selecting one of the datatypes > for labels. (The answer might be obvious but with my limited CBOR skills I > cannot see it). > > Best regards > //Samuel > > > > > > On Thu, Jan 14, 2016 at 5:23 AM, Jim Schaad > wrote: > >> In a piece of mail, Hannes raised the following issue. >> >> Additionally, I also don't like the idea of having a label be either an >> integer or a string. Why cannot we just use integers? This sounds like >> introducing options for no good reasons that just increase the >> implementation complexity >> >> If we make this change, I would have it affect more than just label, it >> would affect all of the registries. >> >> Currently the definition of label is >> >> label = uint / sint / tstring >> >> That is a label can be an unsigned integer, a signed integer or a text >> string. I added the string to the definition of label in order to expand >> the size of the registration space for two byte identifiers. If we are >> willing to accept the decrease of the availability of short labels then we >> can easily remove tstring from the definition. >> >> Part of the reason that is given by Hannes was the idea that this >> increases >> the complexity for little gain. The amount of complexity introduced is >> going to depend for a large part on how the CBOR library is implemented >> and >> the willingness of the programmer to make potentially incorrect >> assumptions. >> (I am currently really guilty of doing this.) >> >> A correct implementation would check both the type of the field and the >> value of the field. An incorrect implementation would fold the two types >> together and just check the value of the field. This means that there is >> already a requirement to have two case statements (or a small number of if >> statements) in order to check if the value is correct. Going from two to >> three does not really add a great deal of complexity as the code for the >> string case would be the same for short strings, it only becomes more >> complicated if the strings are sufficiently long to require a string >> compare >> rather than a cast followed by an integer compare. >> >> While I have allowed for the registration space, I have very carefully >> avoided doing any registrations in the string portion of the registry. I >> have however used this range extensively during code development for >> dealing >> with items which I have not yet assigned code points to. (I.e. the use of >> ES384 rather than the -35 that I just recently assigned to it). >> >> People have expressed concern about the small registration space, this is >> a >> place where we are expanding it, but at some additional complexity. Which >> of the two items is more important? >> >> I would like to resolve this by the end of next week. >> >> Jim >> >> >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >> > > --001a113a731825ddc205295958ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I found the answer to my question in an earlier mail from = you Jim

"If we allow only integers to = be used, then there is a maximum of 255 + 255 values that can be encoded as= a two bytes (a portion of those are actually encoded as single bytes).=C2= =A0 If we add the text string to that then we allow for an additional 180 p= oints where we can have a single byte encoding be added.=C2=A0 (Respecting = the UTF8-ness of the field shrinks it slightly.)"
With this input I think the added value of string label is not = worth the added code complexity.

Best Regards
//Samuel


On Fri, Jan 15, 2016 at 7:11 AM, Samuel Erdtman <s= amuel@erdtman.se> wrote:
Hi Jim,

I like the idea of just having wa= y to do thing i.e. only allow labels to be one of the suggested datatypes= =C2=A0uint / sint / tstring.
<= div>
You say that doing so would limit the number of two byte i= dentifiers to use (clearly). To make an informed=C2=A0decision=C2=A0I think= it would be=C2=A0good to know how many two byte identifier we loos by sele= cting one of the datatypes for labels. (The answer might be obvious but wit= h my limited CBOR skills I cannot see it).

Be= st regards
= //Samuel





On Thu, Jan 14, 2016 at= 5:23 AM, Jim Schaad <ietf@augustcellars.com> wrote:
In a piece of mail, Hannes raised the follo= wing issue.

Additionally, I also don't like the idea of having a label be either an=
integer or a string. Why cannot we just use integers? This sounds like
introducing options for no good reasons that just increase the
implementation complexity

If we make this change, I would have it affect more than just label, it
would affect all of the registries.

Currently the definition of label is

label =3D uint / sint / tstring

That is a label can be an unsigned integer, a signed integer or a text
string.=C2=A0 =C2=A0I added the string to the definition of label in order = to expand
the size of the registration space for two byte identifiers.=C2=A0 If we ar= e
willing to accept the decrease of the availability of short labels then we<= br> can easily remove tstring from the definition.

Part of the reason that is given by Hannes was the idea that this increases=
the complexity for little gain.=C2=A0 The amount of complexity introduced i= s
going to depend for a large part on how the CBOR library is implemented and=
the willingness of the programmer to make potentially incorrect assumptions= .
(I am currently really guilty of doing this.)

A correct implementation would check both the type of the field and the
value of the field.=C2=A0 An incorrect implementation would fold the two ty= pes
together and just check the value of the field.=C2=A0 This means that there= is
already a requirement to have two case statements (or a small number of if<= br> statements) in order to check if the value is correct.=C2=A0 Going from two= to
three does not really add a great deal of complexity as the code for the string case would be the same for short strings, it only becomes more
complicated if the strings are sufficiently long to require a string compar= e
rather than a cast followed by an integer compare.

While I have allowed for the registration space, I have very carefully
avoided doing any registrations in the string portion of the registry.=C2= =A0 I
have however used this range extensively during code development for dealin= g
with items which I have not yet assigned code points to.=C2=A0 (I.e. the us= e of
ES384 rather than the -35 that I just recently assigned to it).

People have expressed concern about the small registration space, this is a=
place where we are expanding it, but at some additional complexity.=C2=A0 W= hich
of the two items is more important?

I would like to resolve this by the end of next week.

Jim


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


--001a113a731825ddc205295958ae-- From nobody Fri Jan 15 01:05:16 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B5B1A8A96 for ; Fri, 15 Jan 2016 01:05:15 -0800 (PST) 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 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 STBpkK5sVA7J for ; Fri, 15 Jan 2016 01:05:13 -0800 (PST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E3E1A8A64 for ; Fri, 15 Jan 2016 01:05:13 -0800 (PST) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 149B741C0CC; Fri, 15 Jan 2016 10:05:12 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id XzmySzFjVz8k; Fri, 15 Jan 2016 10:05:10 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 2E90441C0C4; Fri, 15 Jan 2016 10:05:05 +0100 (CET) Message-ID: <5698B63F.6060007@tzi.org> Date: Fri, 15 Jan 2016 10:05:03 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Jim Schaad References: <021801d14e83$58d1c5c0$0a755140$@augustcellars.com> In-Reply-To: <021801d14e83$58d1c5c0$0a755140$@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] Issue - Change the definition of label X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 09:05:15 -0000 The main reason to have string labels is to make it easier to coordinate label use in the experimental, pre-registration phase. More JSONy, and all that. We could instead adopt a convention of goedelizing those strings into numbers. To give a real-world example for that: one CBOR tag was registered with the number 22098. That is 0x5652, or "RV" when read in a hex dump in LSB order (it is a tag for Perl "Reference Value"). Makes debugging from a hex dump slightly easier... Of course, that only works well for 1, 2, 4, or 8 byte strings. Grüße, Carsten From nobody Sat Jan 16 12:10:39 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCF21A9174 for ; Sat, 16 Jan 2016 12:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 s6NOl_0zVGGa for ; Sat, 16 Jan 2016 12:10:25 -0800 (PST) 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 7747E1A9176 for ; Sat, 16 Jan 2016 12:10:25 -0800 (PST) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id AAE262C9BB; Sat, 16 Jan 2016 12:10:12 -0800 (PST) From: "Jim Schaad" To: "'Samuel Erdtman'" References: <021801d14e83$58d1c5c0$0a755140$@augustcellars.com> In-Reply-To: Date: Sat, 16 Jan 2016 12:07:33 -0800 Message-ID: <05c401d15099$8c89bb30$a59d3190$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05C5_01D15056.7E6A24B0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQHCRCnnp6UelxN3IMEv7q5hqgkvmAC7QHfBAeRqeLufB6yGwA== Archived-At: Cc: 'Hannes Tschofenig' , 'cose' Subject: Re: [COSE] Issue - Change the definition of label X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 20:10:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05C5_01D15056.7E6A24B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not sure that I have a solid answer from you here. =20 You have said that there is enough space with just integer, but you have = also said you want to only have one type. I want to make sure that you = understand that in CBOR integer is two types and not one. Thus in = answer to your original question. What you end up with is =20 Unsigned integer =E2=80=93 255 values Signed integer =E2=80=93 255 values Text strings =E2=80=93 about 180 values (give or take) =20 Are you saying keep both of the integer types and drop the text type or = are you saying use only one of the integer types? =20 Jim =20 =20 From: Samuel Erdtman [mailto:samuel@erdtman.se]=20 Sent: Thursday, January 14, 2016 10:17 PM To: Jim Schaad Cc: cose ; Hannes Tschofenig Subject: Re: [COSE] Issue - Change the definition of label =20 I found the answer to my question in an earlier mail from you Jim =20 "If we allow only integers to be used, then there is a maximum of 255 + = 255 values that can be encoded as a two bytes (a portion of those are = actually encoded as single bytes). If we add the text string to that = then we allow for an additional 180 points where we can have a single = byte encoding be added. (Respecting the UTF8-ness of the field shrinks = it slightly.)" =20 With this input I think the added value of string label is not worth the = added code complexity. =20 Best Regards //Samuel =20 =20 On Fri, Jan 15, 2016 at 7:11 AM, Samuel Erdtman > wrote: Hi Jim, =20 I like the idea of just having way to do thing i.e. only allow labels to = be one of the suggested datatypes uint / sint / tstring. =20 You say that doing so would limit the number of two byte identifiers to = use (clearly). To make an informed decision I think it would be good to = know how many two byte identifier we loos by selecting one of the = datatypes for labels. (The answer might be obvious but with my limited = CBOR skills I cannot see it). =20 Best regards //Samuel =20 =20 =20 =20 =20 On Thu, Jan 14, 2016 at 5:23 AM, Jim Schaad > wrote: In a piece of mail, Hannes raised the following issue. Additionally, I also don't like the idea of having a label be either an integer or a string. Why cannot we just use integers? This sounds like introducing options for no good reasons that just increase the implementation complexity If we make this change, I would have it affect more than just label, it would affect all of the registries. Currently the definition of label is label =3D uint / sint / tstring That is a label can be an unsigned integer, a signed integer or a text string. I added the string to the definition of label in order to = expand the size of the registration space for two byte identifiers. If we are willing to accept the decrease of the availability of short labels then = we can easily remove tstring from the definition. Part of the reason that is given by Hannes was the idea that this = increases the complexity for little gain. The amount of complexity introduced is going to depend for a large part on how the CBOR library is implemented = and the willingness of the programmer to make potentially incorrect = assumptions. (I am currently really guilty of doing this.) A correct implementation would check both the type of the field and the value of the field. An incorrect implementation would fold the two = types together and just check the value of the field. This means that there = is already a requirement to have two case statements (or a small number of = if statements) in order to check if the value is correct. Going from two = to three does not really add a great deal of complexity as the code for the string case would be the same for short strings, it only becomes more complicated if the strings are sufficiently long to require a string = compare rather than a cast followed by an integer compare. While I have allowed for the registration space, I have very carefully avoided doing any registrations in the string portion of the registry. = I have however used this range extensively during code development for = dealing with items which I have not yet assigned code points to. (I.e. the use = of ES384 rather than the -35 that I just recently assigned to it). People have expressed concern about the small registration space, this = is a place where we are expanding it, but at some additional complexity. = Which of the two items is more important? I would like to resolve this by the end of next week. Jim _______________________________________________ COSE mailing list COSE@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose =20 =20 ------=_NextPart_000_05C5_01D15056.7E6A24B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I am not sure that I have a solid answer from you = here.

 

You have said that there is enough space with just integer, but you = have also said you want to only have one type. I want to make sure that = you understand that in CBOR integer is two types and not one.=C2=A0 Thus = in answer to your original question.=C2=A0 What you end up with = is

 

Unsigned integer =E2=80=93 255 values

Signed integer =E2=80=93 255 values

Text strings =E2=80=93 about 180 values (give or = take)

 

Are you saying keep both of the integer types and drop the text type or = are you saying use only one of the integer = types?

 

Jim

 

 

From:<= /b> = Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Thursday, = January 14, 2016 10:17 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: cose <cose@ietf.org>; = Hannes Tschofenig <hannes.tschofenig@gmx.net>
Subject: = Re: [COSE] Issue - Change the definition of = label

 

I found = the answer to my question in an earlier mail from you = Jim

 

"If we allow only integers to be used, then there is a maximum of 255 + = 255 values that can be encoded as a two bytes (a portion of those are = actually encoded as single bytes).  If we add the text string to = that then we allow for an additional 180 points where we can have a = single byte encoding be added.  (Respecting the UTF8-ness of the = field shrinks it slightly.)"

 

With this input I think the added value of string = label is not worth the added code = complexity.

 

Best Regards

//Samuel

 

 

On Fri, = Jan 15, 2016 at 7:11 AM, Samuel Erdtman <samuel@erdtman.se> = wrote:

Hi = Jim,

 

I = like the idea of just having way to do thing i.e. only allow labels to = be one of the suggested datatypes uint / sint / = tstring.

 

You say that doing so = would limit the number of two byte identifiers to use (clearly). To make = an informed decision I think it would be good to know how = many two byte identifier we loos by selecting one of the datatypes for = labels. (The answer might be obvious but with my limited CBOR skills I = cannot see it).

 

Best = regards

//Samuel

 

 

 

 

 

On Thu, Jan 14, 2016 at 5:23 AM, Jim Schaad <ietf@augustcellars.com> = wrote:

In a = piece of mail, Hannes raised the following issue.

Additionally, I = also don't like the idea of having a label be either an
integer or a = string. Why cannot we just use integers? This sounds like
introducing = options for no good reasons that just increase the
implementation = complexity

If we make this change, I would have it affect more = than just label, it
would affect all of the = registries.

Currently the definition of label is

label =3D = uint / sint / tstring

That is a label can be an unsigned integer, = a signed integer or a text
string.   I added the string to = the definition of label in order to expand
the size of the = registration space for two byte identifiers.  If we are
willing = to accept the decrease of the availability of short labels then = we
can easily remove tstring from the definition.

Part of the = reason that is given by Hannes was the idea that this increases
the = complexity for little gain.  The amount of complexity introduced = is
going to depend for a large part on how the CBOR library is = implemented and
the willingness of the programmer to make potentially = incorrect assumptions.
(I am currently really guilty of doing = this.)

A correct implementation would check both the type of the = field and the
value of the field.  An incorrect implementation = would fold the two types
together and just check the value of the = field.  This means that there is
already a requirement to have = two case statements (or a small number of if
statements) in order to = check if the value is correct.  Going from two to
three does not = really add a great deal of complexity as the code for the
string case = would be the same for short strings, it only becomes more
complicated = if the strings are sufficiently long to require a string = compare
rather than a cast followed by an integer = compare.

While I have allowed for the registration space, I have = very carefully
avoided doing any registrations in the string portion = of the registry.  I
have however used this range extensively = during code development for dealing
with items which I have not yet = assigned code points to.  (I.e. the use of
ES384 rather than the = -35 that I just recently assigned to it).

People have expressed = concern about the small registration space, this is a
place where we = are expanding it, but at some additional complexity.  Which
of = the two items is more important?

I would like to resolve this by = the end of next = week.

Jim


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

 

 

------=_NextPart_000_05C5_01D15056.7E6A24B0-- From nobody Sun Jan 17 04:39:47 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4C81A1A17 for ; Sun, 17 Jan 2016 04:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 akSc0vC4MqJ9 for ; Sun, 17 Jan 2016 04:39:42 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 010581A1A16 for ; Sun, 17 Jan 2016 04:39:41 -0800 (PST) Received: by mail-qg0-x236.google.com with SMTP id 6so461372635qgy.1 for ; Sun, 17 Jan 2016 04:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7d5wQPv08jnTOx7mSNinQTIJdfPLtw9mS48w6XD80tQ=; b=JhhnB4y2zpRn0Gds/4wEbaSDTdwXZKDisMQ0FiFEPB1bYiEhOfRR9JpyTwtL8o6Jg2 Hp12U3cc7rJg3W3MgePgbUqJ7JQtpt3d6CeVOQ9rxNoWaoJzGR7VlJYaaOcT29RuzGRu OW1/pSGZWIl/3Z7QlM4dC+m5qe0SkLFejkvyd0toSl9Mu8uS8AgO5p1FXG9i4HFl/Pfz LVyVS2ZPyAqOjkQB/HD2tHbTnwozbCOdg2WwdBGlpdi1zECEh9R617DYDK/H49hR9slZ xP3jSnXQ8JI65718DgAgKzN9mJR+r450IuQYLbLP4/kDRvs/zURdy/MCDE/N8lzHJBd1 wQSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7d5wQPv08jnTOx7mSNinQTIJdfPLtw9mS48w6XD80tQ=; b=Frq3+Q7GCPaPbVw55bZ9Ksw4F0Pa4PVtjHFfDce+SxQn0PMuH5YRDMcXhldKtQXV0D F2+dB0PFcYqon7AprGwQcLHooSEQHHuucU0p81gAstpgu+07aZRNDXMSY6F1pH7XvANv qNVvkn66M0hLzSk2WKNlpAxSXealc/vpk2gdY+i4fJlL32gsgO7d8Mc6KXPeIWJreHAa erpcIKIJQDotAXraIRggbeI8fIuy5Io6KBz9JagAEmgQHb7BrABIOLtiB+VaUT1sBNZh qrcDRsQ5NqXOoNufZTAM0XjvzSmcqLc/khvILjk2aPVPpWyg8npjHVHf0fWggROSmBVz zWmQ== X-Gm-Message-State: ALoCoQlA02SSrMqdPzI1+LFYLQOq0NtGjXffjfwbYJfF2vNP7gbKSZdNJEt6OsrZYjTnFGBPUFYVhH6U7IRdvX2Wcm7/X7XrEA== MIME-Version: 1.0 X-Received: by 10.140.28.161 with SMTP id 30mr24247533qgz.36.1453034380997; Sun, 17 Jan 2016 04:39:40 -0800 (PST) Received: by 10.55.179.1 with HTTP; Sun, 17 Jan 2016 04:39:40 -0800 (PST) In-Reply-To: <05c401d15099$8c89bb30$a59d3190$@augustcellars.com> References: <021801d14e83$58d1c5c0$0a755140$@augustcellars.com> <05c401d15099$8c89bb30$a59d3190$@augustcellars.com> Date: Sun, 17 Jan 2016 13:39:40 +0100 Message-ID: From: Samuel Erdtman To: Jim Schaad Content-Type: multipart/alternative; boundary=001a1145822c2050f0052986eec7 Archived-At: Cc: Hannes Tschofenig , cose Subject: Re: [COSE] Issue - Change the definition of label X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 12:39:45 -0000 --001a1145822c2050f0052986eec7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To really get the desired simplification of the code I think we should go for only one of the integer options. If I look at the JOSE specifications and the number of labels defined there I get the following by doing a quick look through. JWS (https://tools.ietf.org/html/rfc7515) has 11 registered header parameter (if I=C2=B4m counting correctly) JWT (https://tools.ietf.org/html/rfc7515) has 2 header parmeters and 7 claims names (if I=C2=B4m counting correctly) JWE (https://tools.ietf.org/html/rfc7516) has 13 registered header parameter (if I=C2=B4m counting correctly) JWA (https://tools.ietf.org/html/rfc7518) has 10 registered header parameter and 14 key parameters (if I=C2=B4m counting correctly) They come from different context so some of them could overlap without problem e.g. header parameters and claims does not share context and can thus the same numbers could be reused. If we despite this sum all of them we end up at 57 i.e quite a good margin to 255 and when we have reached that limit I guess we could have three byte identifiers. With this said I don=C2=B4t have a strong opinion but I prefer this choice. Best Regards //Samuel On Sat, Jan 16, 2016 at 9:07 PM, Jim Schaad wrote: > I am not sure that I have a solid answer from you here. > > > > You have said that there is enough space with just integer, but you have > also said you want to only have one type. I want to make sure that you > understand that in CBOR integer is two types and not one. Thus in answer > to your original question. What you end up with is > > > > Unsigned integer =E2=80=93 255 values > > Signed integer =E2=80=93 255 values > > Text strings =E2=80=93 about 180 values (give or take) > > > > Are you saying keep both of the integer types and drop the text type or > are you saying use only one of the integer types? > > > > Jim > > > > > > *From:* Samuel Erdtman [mailto:samuel@erdtman.se] > *Sent:* Thursday, January 14, 2016 10:17 PM > *To:* Jim Schaad > *Cc:* cose ; Hannes Tschofenig > *Subject:* Re: [COSE] Issue - Change the definition of label > > > > I found the answer to my question in an earlier mail from you Jim > > > > "If we allow only integers to be used, then there is a maximum of 255 + > 255 values that can be encoded as a two bytes (a portion of those are > actually encoded as single bytes). If we add the text string to that the= n > we allow for an additional 180 points where we can have a single byte > encoding be added. (Respecting the UTF8-ness of the field shrinks it > slightly.)" > > > > With this input I think the added value of string label is not worth the > added code complexity. > > > > Best Regards > > //Samuel > > > > > > On Fri, Jan 15, 2016 at 7:11 AM, Samuel Erdtman wrote= : > > Hi Jim, > > > > I like the idea of just having way to do thing i.e. only allow labels to > be one of the suggested datatypes uint / sint / tstring. > > > > You say that doing so would limit the number of two byte identifiers to > use (clearly). To make an informed decision I think it would be good to > know how many two byte identifier we loos by selecting one of the datatyp= es > for labels. (The answer might be obvious but with my limited CBOR skills = I > cannot see it). > > > > Best regards > > //Samuel > > > > > > > > > > > > On Thu, Jan 14, 2016 at 5:23 AM, Jim Schaad > wrote: > > In a piece of mail, Hannes raised the following issue. > > Additionally, I also don't like the idea of having a label be either an > integer or a string. Why cannot we just use integers? This sounds like > introducing options for no good reasons that just increase the > implementation complexity > > If we make this change, I would have it affect more than just label, it > would affect all of the registries. > > Currently the definition of label is > > label =3D uint / sint / tstring > > That is a label can be an unsigned integer, a signed integer or a text > string. I added the string to the definition of label in order to expan= d > the size of the registration space for two byte identifiers. If we are > willing to accept the decrease of the availability of short labels then w= e > can easily remove tstring from the definition. > > Part of the reason that is given by Hannes was the idea that this increas= es > the complexity for little gain. The amount of complexity introduced is > going to depend for a large part on how the CBOR library is implemented a= nd > the willingness of the programmer to make potentially incorrect > assumptions. > (I am currently really guilty of doing this.) > > A correct implementation would check both the type of the field and the > value of the field. An incorrect implementation would fold the two types > together and just check the value of the field. This means that there is > already a requirement to have two case statements (or a small number of i= f > statements) in order to check if the value is correct. Going from two to > three does not really add a great deal of complexity as the code for the > string case would be the same for short strings, it only becomes more > complicated if the strings are sufficiently long to require a string > compare > rather than a cast followed by an integer compare. > > While I have allowed for the registration space, I have very carefully > avoided doing any registrations in the string portion of the registry. I > have however used this range extensively during code development for > dealing > with items which I have not yet assigned code points to. (I.e. the use o= f > ES384 rather than the -35 that I just recently assigned to it). > > People have expressed concern about the small registration space, this is= a > place where we are expanding it, but at some additional complexity. Whic= h > of the two items is more important? > > I would like to resolve this by the end of next week. > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > > > > --001a1145822c2050f0052986eec7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To really get the desired simplification of the code I thi= nk we should go for only one of the integer options.

If = I look at the JOSE specifications and the number of labels defined there I = get the following by doing a quick look through.
JWS (https://tools.ietf.org/html/rfc7515) has 11 registered header parameter (if I=C2=B4m counting correctly)
JWT (https://tools.ie= tf.org/html/rfc7515) has 2 header parmeters and 7 claims names=C2=A0(if= I=C2=B4m counting correctly)
JWE (https://tools.ietf.org/html/rfc7516) has 13=C2=A0regi= stered header parameter (if I=C2=B4m counting correctly)
JWA (https://tools.ietf.org/html/rf= c7518) has 10=C2=A0registered header parameter=C2=A0and 14 key paramete= rs=C2=A0(if I=C2=B4m counting correctly)
They come from different= context so some of them could overlap without problem e.g. header paramete= rs and claims does not share context and can thus the same numbers could be= reused. If we despite this sum all of them we end up at 57 i.e quite a goo= d margin to 255 and when we have reached that limit I guess we could have t= hree byte identifiers.

With this said I don=C2= =B4t have a strong opinion but I prefer this choice.

Best Regards
//Samuel





On Sat, Jan 16, 2016 at 9:07 PM, Jim Schaad <ietf@a= ugustcellars.com> wrote:

I am not sure that I have a solid answer from you here.=

=C2=A0

You have said that th= ere is enough space with just integer, but you have also said you want to o= nly have one type. I want to make sure that you understand that in CBOR int= eger is two types and not one.=C2=A0 Thus in answer to your original questi= on.=C2=A0 What you end up with is

=C2=A0

= Unsigned integer =E2=80=93 255 values

Signed integer =E2=80=93 255 values=

Text strings= =E2=80=93 about 180 values (give or take)

=C2=A0

Are you saying keep both of the integer types and d= rop the text type or are you saying use only one of the integer types?

=C2=A0<= /u>

Jim

=C2=A0

<= p class=3D"MsoNormal">=C2=A0

=

From: Samuel Erdtman [= mailto:samuel@erdtma= n.se]
Sent: Thursday, January 14, 2016 10:17 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: cose <cose@ietf.org>; Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net>
Subject: Re: [COSE] Issue - Change the de= finition of label

=C2=A0

I found the answer to my question in an earlier mail from you Jim<= u>

=C2=A0

"If we allow only integers to be u= sed, then there is a maximum of 255 + 255 values that can be encoded as a t= wo bytes (a portion of those are actually encoded as single bytes).=C2=A0 I= f we add the text string to that then we allow for an additional 180 points= where we can have a single byte encoding be added.=C2=A0 (Respecting the U= TF8-ness of the field shrinks it slightly.)"

<= /div>

=C2=A0

With this input I think the added value of string label is = not worth the added code complexity.

=C2=A0

Be= st Regards

//Samuel

=C2=A0

=C2=A0

On Fri, Jan 15, 2016 at 7:11 AM, Samuel Erdtman <samuel@erdtman.se> w= rote:

=

Hi Jim,

=C2=A0

I like the = idea of just having way to do thing i.e. only allow labels to be one of the= suggested datatypes=C2=A0uint / sint / tst= ring.

=C2= =A0

You say that doing so would limit the number of two byte identifiers t= o use (clearly). To make an informed=C2=A0decision=C2=A0I think it would be= =C2=A0good to know how many two byte identifier we loos by selecting one of= the datatypes for labels. (The answer might be obvious but with my limited= CBOR skills I cannot see it).

=C2=A0

Best regards

//S= amuel

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Thu, Jan 14, 2016 at 5:23 AM, Jim Schaad <ietf@augustcellars= .com> wrote:

In a piece of mail, Hannes raised the = following issue.

Additionally, I also don't like the idea of hav= ing a label be either an
integer or a string. Why cannot we just use int= egers? This sounds like
introducing options for no good reasons that jus= t increase the
implementation complexity

If we make this change, = I would have it affect more than just label, it
would affect all of the = registries.

Currently the definition of label is

label =3D ui= nt / sint / tstring

That is a label can be an unsigned integer, a si= gned integer or a text
string.=C2=A0 =C2=A0I added the string to the def= inition of label in order to expand
the size of the registration space f= or two byte identifiers.=C2=A0 If we are
willing to accept the decrease = of the availability of short labels then we
can easily remove tstring fr= om the definition.

Part of the reason that is given by Hannes was th= e idea that this increases
the complexity for little gain.=C2=A0 The amo= unt of complexity introduced is
going to depend for a large part on how = the CBOR library is implemented and
the willingness of the programmer to= make potentially incorrect assumptions.
(I am currently really guilty o= f doing this.)

A correct implementation would check both the type of= the field and the
value of the field.=C2=A0 An incorrect implementation= would fold the two types
together and just check the value of the field= .=C2=A0 This means that there is
already a requirement to have two case = statements (or a small number of if
statements) in order to check if the= value is correct.=C2=A0 Going from two to
three does not really add a g= reat deal of complexity as the code for the
string case would be the sam= e for short strings, it only becomes more
complicated if the strings are= sufficiently long to require a string compare
rather than a cast follow= ed by an integer compare.

While I have allowed for the registration = space, I have very carefully
avoided doing any registrations in the stri= ng portion of the registry.=C2=A0 I
have however used this range extensi= vely during code development for dealing
with items which I have not yet= assigned code points to.=C2=A0 (I.e. the use of
ES384 rather than the -= 35 that I just recently assigned to it).

People have expressed conce= rn about the small registration space, this is a
place where we are expa= nding it, but at some additional complexity.=C2=A0 Which
of the two item= s is more important?

I would like to resolve this by the end of next= week.

Jim


______________________________________________= _
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose<= u>

=C2=A0

=C2=A0<= u>


--001a1145822c2050f0052986eec7-- From nobody Thu Jan 21 08:22:08 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F5B1A1B27 for ; Thu, 21 Jan 2016 08:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=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 x-Ugeppv9bHS for ; Thu, 21 Jan 2016 08:22:05 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C571A908C for ; Thu, 21 Jan 2016 08:22:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id AFA60E203A; Thu, 21 Jan 2016 11:21:32 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 32682-09; Thu, 21 Jan 2016 11:21:28 -0500 (EST) Received: from securerf.ihtfp.org (IHTFP-DHCP-204.IHTFP.ORG [192.168.248.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id C7CD7E2030; Thu, 21 Jan 2016 11:21:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1453393287; bh=Yh+R8cphQtlHZuc2+TS7fy6gSxVwJmEDfymJ7eC3AEg=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=QXSd9SNkLFbaogrkpnLN9XsnU1LloIqI3195voNCunSPLlaG+k86qN9vQlqEB1ucM fDQ2N3r5Y/WgLIyUNkQ8JrMVT+cDlqntQltW25EiuLST0w2/djOvm0kXHRD7+GZ2z6 LZGHYmV+PbTQks0wNjZvw0s1zd1s6U892nwXNrN4= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id u0LGLQbw010284; Thu, 21 Jan 2016 11:21:26 -0500 From: Derek Atkins To: Carsten Bormann References: <021801d14e83$58d1c5c0$0a755140$@augustcellars.com> <5698B63F.6060007@tzi.org> Date: Thu, 21 Jan 2016 11:21:26 -0500 In-Reply-To: <5698B63F.6060007@tzi.org> (Carsten Bormann's message of "Fri, 15 Jan 2016 10:05:03 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Jim Schaad , cose@ietf.org Subject: Re: [COSE] Issue - Change the definition of label X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 16:22:06 -0000 Hi Carsten Bormann writes: > The main reason to have string labels is to make it easier to coordinate > label use in the experimental, pre-registration phase. > More JSONy, and all that. > > We could instead adopt a convention of goedelizing those strings into > numbers. > To give a real-world example for that: one CBOR tag was registered with > the number 22098. > That is 0x5652, or "RV" when read in a hex dump in LSB order (it is a > tag for Perl "Reference Value"). Makes debugging from a hex dump > slightly easier... > Of course, that only works well for 1, 2, 4, or 8 byte strings. Coming at this a week later, but I'm with Carsten. I think allowing string labels (in general) is extremely useful for extension prototyping, or for making "private-use" data structures that could have a low probability of clashing with someone else's private-use label. I'll note that the code required to support all three data types (sint/uint/tstring) is NOT significant, and frankly IMHO it does not add much complexity. > Gr=C3=BC=C3=9Fe, Carsten -derek --=20 Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Thu Jan 21 15:31:14 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE22F1B2A40 for ; Thu, 21 Jan 2016 15:31:12 -0800 (PST) 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 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 bAigfZZ5yfKJ for ; Thu, 21 Jan 2016 15:31:11 -0800 (PST) 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 701121B2A38 for ; Thu, 21 Jan 2016 15:31:11 -0800 (PST) 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: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id A6FA42CA13; Thu, 21 Jan 2016 15:31:10 -0800 (PST) From: "Jim Schaad" To: "'Derek Atkins'" , "'Carsten Bormann'" References: <021801d14e83$58d1c5c0$0a755140$@augustcellars.com> <5698B63F.6060007@tzi.org> In-Reply-To: Date: Thu, 21 Jan 2016 15:28:35 -0800 Message-ID: <020a01d154a3$73413230$59c39690$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQHCRCnnp6UelxN3IMEv7q5hqgkvmAIw1DMqAROo34CfCpoicA== Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] Issue - Change the definition of label X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 23:31:13 -0000 You are not too late to weigh in on this issue, however you have made it = impossible for me to say that there is a consensus one way or the other = on it. There is basically an even split. Chairs can you please weight in? Jim > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Thursday, January 21, 2016 8:21 AM > To: Carsten Bormann > Cc: Jim Schaad ; cose@ietf.org > Subject: Re: [COSE] Issue - Change the definition of label >=20 > Hi >=20 > Carsten Bormann writes: >=20 > > The main reason to have string labels is to make it easier to > > coordinate label use in the experimental, pre-registration phase. > > More JSONy, and all that. > > > > We could instead adopt a convention of goedelizing those strings = into > > numbers. > > To give a real-world example for that: one CBOR tag was registered > > with the number 22098. > > That is 0x5652, or "RV" when read in a hex dump in LSB order (it is = a > > tag for Perl "Reference Value"). Makes debugging from a hex dump > > slightly easier... > > Of course, that only works well for 1, 2, 4, or 8 byte strings. >=20 > Coming at this a week later, but I'm with Carsten. I think allowing = string labels > (in general) is extremely useful for extension prototyping, or for = making > "private-use" data structures that could have a low probability of = clashing with > someone else's private-use label. >=20 > I'll note that the code required to support all three data types > (sint/uint/tstring) is NOT significant, and frankly IMHO it does not = add much > complexity. >=20 > > Gr=C3=BC=C3=9Fe, Carsten >=20 > -derek > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available From nobody Thu Jan 21 15:35:59 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CA01B2A46 for ; Thu, 21 Jan 2016 15:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 gxkcpcL0K7NB for ; Thu, 21 Jan 2016 15:35:56 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext4.iad.github.net [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D301B2A44 for ; Thu, 21 Jan 2016 15:35:56 -0800 (PST) Date: Thu, 21 Jan 2016 15:35:55 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1453419355; bh=UnUYkE19FC3+GxWsSK9x/I16vScpriYA+r9KlgFR/gU=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=GHU5SvjAjWdYdkzXe5fRFKUYLq5rOUqN8XpMy8G+Lv496wP2AO0gKOLvBIGQI+BCm NUVgq9GVp3lYPkSF7WeefKhiIS9gc1oca+CDh4YI6VJSb+c0fWymH/W1HMjZ3zEICG 4E/l8jHJ6HqMMFNq3RtGO5op6RAWwmhYx5qHritk= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56a16b5b6be07_5a3a3ff5f87d129c26061f"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jimsch X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] add the value type 'bstr' to counter signature (#52) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 23:35:58 -0000 ----==_mimepart_56a16b5b6be07_5a3a3ff5f87d129c26061f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Per discussion on the list, this has been changed from a request to modify the current existing counter signature attribute to defining a new one. The reason for the change in the request is that the input for the new counter signature computation process should reflect the ToBeSigned structure of the COSE_Sign1 rather than the full COSE_Sign structure. This better reflects the circumstances that it is being designed for. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/52#issuecomment-173750319 ----==_mimepart_56a16b5b6be07_5a3a3ff5f87d129c26061f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Per discussion on the list, this has been changed from a request to modify the current existing counter signature attribute to defining a new one. The reason for the change in the request is that the input for the new counter signature computation process should reflect the ToBeSigned structure of the COSE_Sign1 rather than the full COSE_Sign structure. This better reflects the circumstances that it is being designed for.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_56a16b5b6be07_5a3a3ff5f87d129c26061f-- From nobody Thu Jan 21 22:02:45 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274901A0217 for ; Thu, 21 Jan 2016 22:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 iURofXsB65dS for ; Thu, 21 Jan 2016 22:02:41 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3EDA1A0210 for ; Thu, 21 Jan 2016 22:02:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MGeHeNSOXDAjSm5uyPhoOS60Lj0csIY8TIehweMASYo=; b=W8d/OTxmYZNExZ5vvg+bcuUOiE/70YWIdrmtUO8Zz4IbPQX/4OZINbeimKQG+9/71Z6f61Cz/aL6bV3otHMlkeSJy2UTlMwbRo85hExrLBlQZ2S1x43TN4dzO+0UCdfk9NuYouGj2b3vgVrsYM2yMceRgu4kKJHouBptvUK+B6o= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 22 Jan 2016 06:02:24 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Fri, 22 Jan 2016 06:02:24 +0000 From: Mike Jones To: Jim Schaad , 'Derek Atkins' , 'Carsten Bormann' Thread-Topic: [COSE] Issue - Change the definition of label Thread-Index: AdFOgH4yRUypsA5ZRuy/QyLeWSCneAA81OaAAT0ELREADuQIgAANvFuQ Date: Fri, 22 Jan 2016 06:02:23 +0000 Message-ID: References: <021801d14e83$58d1c5c0$0a755140$@augustcellars.com> <5698B63F.6060007@tzi.org> <020a01d154a3$73413230$59c39690$@augustcellars.com> In-Reply-To: <020a01d154a3$73413230$59c39690$@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: [50.47.85.157] x-ms-office365-filtering-correlation-id: 794a2c84-98c2-4c72-fde5-08d322f19949 x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:zXi+NuCfrnKVMI50Neg3YWRH6qr91xUjoHjBTtyNDaT5VK4/Qny/BVgW4udyfC6nwDUonlgewwcVBBec8nWZA2VXxkgQfQsQYLANi4rSXhdBYoHpsZ8Zi6RSpjzFBBXJ17J1Obg1tQZjG+hzvry1Vg==; 24:LQdpnEvMvYw8arxaSh174CniQvnjH6BmjL04J29yg7zB8VdS8+3ar4aSGME0S8Fkv3P28yXP2dO4UKaZD3Gwo20brA4a6NLLSHuJ7ZU+P1U= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 08296C9B35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(189002)(377454003)(199003)(15975445007)(87936001)(66066001)(106356001)(5004730100002)(19580405001)(105586002)(92566002)(8990500004)(5001960100002)(5008740100001)(54356999)(11100500001)(4326007)(10090500001)(2906002)(77096005)(19580395003)(1096002)(10290500002)(586003)(81156007)(97736004)(10400500002)(76176999)(50986999)(2900100001)(5002640100001)(33656002)(1220700001)(5005710100001)(102836003)(2950100001)(99286002)(6116002)(189998001)(76576001)(3846002)(40100003)(93886004)(101416001)(5003600100002)(74316001)(5001770100001)(122556002)(86612001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 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: 22 Jan 2016 06:02:23.8753 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] Issue - Change the definition of label X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 06:02:44 -0000 U3RyaW5nIGxhYmVscyBhcmUgdmVyeSB2YWx1YWJsZS4gIFBsZWFzZSBrZWVwIHRoZW0uDQoNCgkJ CQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDT1NFIFttYWls dG86Y29zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltIFNjaGFhZA0KU2VudDog VGh1cnNkYXksIEphbnVhcnkgMjEsIDIwMTYgMzoyOSBQTQ0KVG86ICdEZXJlayBBdGtpbnMnIDxk ZXJla0BpaHRmcC5jb20+OyAnQ2Fyc3RlbiBCb3JtYW5uJyA8Y2Fib0B0emkub3JnPg0KQ2M6IGNv c2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ09TRV0gSXNzdWUgLSBDaGFuZ2UgdGhlIGRlZmlu aXRpb24gb2YgbGFiZWwNCg0KWW91IGFyZSBub3QgdG9vIGxhdGUgdG8gd2VpZ2ggaW4gb24gdGhp cyBpc3N1ZSwgaG93ZXZlciB5b3UgaGF2ZSBtYWRlIGl0IGltcG9zc2libGUgZm9yIG1lIHRvIHNh eSB0aGF0IHRoZXJlIGlzIGEgY29uc2Vuc3VzIG9uZSB3YXkgb3IgdGhlIG90aGVyIG9uIGl0LiAg VGhlcmUgaXMgYmFzaWNhbGx5IGFuIGV2ZW4gc3BsaXQuDQoNCkNoYWlycyBjYW4geW91IHBsZWFz ZSB3ZWlnaHQgaW4/DQoNCkppbQ0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogRGVyZWsgQXRraW5zIFttYWlsdG86ZGVyZWtAaWh0ZnAuY29tXQ0KPiBTZW50OiBUaHVy c2RheSwgSmFudWFyeSAyMSwgMjAxNiA4OjIxIEFNDQo+IFRvOiBDYXJzdGVuIEJvcm1hbm4gPGNh Ym9AdHppLm9yZz4NCj4gQ2M6IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+OyBj b3NlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQ09TRV0gSXNzdWUgLSBDaGFuZ2UgdGhlIGRl ZmluaXRpb24gb2YgbGFiZWwNCj4gDQo+IEhpDQo+IA0KPiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9A dHppLm9yZz4gd3JpdGVzOg0KPiANCj4gPiBUaGUgbWFpbiByZWFzb24gdG8gaGF2ZSBzdHJpbmcg bGFiZWxzIGlzIHRvIG1ha2UgaXQgZWFzaWVyIHRvIA0KPiA+IGNvb3JkaW5hdGUgbGFiZWwgdXNl IGluIHRoZSBleHBlcmltZW50YWwsIHByZS1yZWdpc3RyYXRpb24gcGhhc2UuDQo+ID4gTW9yZSBK U09OeSwgYW5kIGFsbCB0aGF0Lg0KPiA+DQo+ID4gV2UgY291bGQgaW5zdGVhZCBhZG9wdCBhIGNv bnZlbnRpb24gb2YgZ29lZGVsaXppbmcgdGhvc2Ugc3RyaW5ncyANCj4gPiBpbnRvIG51bWJlcnMu DQo+ID4gVG8gZ2l2ZSBhIHJlYWwtd29ybGQgZXhhbXBsZSBmb3IgdGhhdDogb25lIENCT1IgdGFn IHdhcyByZWdpc3RlcmVkIA0KPiA+IHdpdGggdGhlIG51bWJlciAyMjA5OC4NCj4gPiBUaGF0IGlz IDB4NTY1Miwgb3IgIlJWIiB3aGVuIHJlYWQgaW4gYSBoZXggZHVtcCBpbiBMU0Igb3JkZXIgKGl0 IGlzIA0KPiA+IGEgdGFnIGZvciBQZXJsICJSZWZlcmVuY2UgVmFsdWUiKS4gIE1ha2VzIGRlYnVn Z2luZyBmcm9tIGEgaGV4IGR1bXAgDQo+ID4gc2xpZ2h0bHkgZWFzaWVyLi4uDQo+ID4gT2YgY291 cnNlLCB0aGF0IG9ubHkgd29ya3Mgd2VsbCBmb3IgMSwgMiwgNCwgb3IgOCBieXRlIHN0cmluZ3Mu DQo+IA0KPiBDb21pbmcgYXQgdGhpcyBhIHdlZWsgbGF0ZXIsIGJ1dCBJJ20gd2l0aCBDYXJzdGVu LiAgSSB0aGluayBhbGxvd2luZyANCj4gc3RyaW5nIGxhYmVscyAoaW4gZ2VuZXJhbCkgaXMgZXh0 cmVtZWx5IHVzZWZ1bCBmb3IgZXh0ZW5zaW9uIA0KPiBwcm90b3R5cGluZywgb3IgZm9yIG1ha2lu ZyAicHJpdmF0ZS11c2UiIGRhdGEgc3RydWN0dXJlcyB0aGF0IGNvdWxkIA0KPiBoYXZlIGEgbG93 IHByb2JhYmlsaXR5IG9mIGNsYXNoaW5nIHdpdGggc29tZW9uZSBlbHNlJ3MgcHJpdmF0ZS11c2Ug bGFiZWwuDQo+IA0KPiBJJ2xsIG5vdGUgdGhhdCB0aGUgY29kZSByZXF1aXJlZCB0byBzdXBwb3J0 IGFsbCB0aHJlZSBkYXRhIHR5cGVzDQo+IChzaW50L3VpbnQvdHN0cmluZykgaXMgTk9UIHNpZ25p ZmljYW50LCBhbmQgZnJhbmtseSBJTUhPIGl0IGRvZXMgbm90IA0KPiBhZGQgbXVjaCBjb21wbGV4 aXR5Lg0KPiANCj4gPiBHcsO8w59lLCBDYXJzdGVuDQo+IA0KPiAtZGVyZWsNCj4gLS0NCj4gICAg ICAgIERlcmVrIEF0a2lucywgU0IgJzkzIE1JVCBFRSwgU00gJzk1IE1JVCBNZWRpYSBMYWJvcmF0 b3J5DQo+ICAgICAgICBNZW1iZXIsIE1JVCBTdHVkZW50IEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg Qm9hcmQgIChTSVBCKQ0KPiAgICAgICAgVVJMOiBodHRwOi8vd2ViLm1pdC5lZHUvd2FybG9yZC8g ICAgUFAtQVNFTC1JQSAgICAgTjFOV0gNCj4gICAgICAgIHdhcmxvcmRATUlULkVEVSAgICAgICAg ICAgICAgICAgICAgICAgIFBHUCBrZXkgYXZhaWxhYmxlDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDT1NFIG1haWxpbmcgbGlzdA0KQ09TRUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQo= From nobody Fri Jan 22 01:18:24 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78581ACE2B for ; Fri, 22 Jan 2016 01:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 mL2Oy7eDsSQf for ; Fri, 22 Jan 2016 01:18:20 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext6.iad.github.net [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D5D1ACE29 for ; Fri, 22 Jan 2016 01:18:20 -0800 (PST) Date: Fri, 22 Jan 2016 01:18:19 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1453454299; bh=k3ddtFFI1TyBzqWOs1E1HTVOZTZsFPYx+DxdUjM6rg4=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=k+vUno6kbSSrCSnX3rSb4qnLtXRiUchfmam7CLziyFyBgq3NUDObieuBv+icugizm IIoTXZb5DhAtdgkCClWERdOfAaOxhVUnTjLcTuJqTDS+222obS516/oKpitGJQG2rm ElsCfIah3llwetlk63cJ9cAm/SJ2tdU+5jbSfTTk= From: fpalombini To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56a1f3db95e5a_7fc53ffb06e3d2bc2192966"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: fpalombini X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: [COSE] [cose-issues] Define detached content (#58) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 09:18:23 -0000 ----==_mimepart_56a1f3db95e5a_7fc53ffb06e3d2bc2192966 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Could you add a definition of "detached content" for (at least) COSE_Sign1 and COSE_Mac0? Right now detached content is mentioned in the draft only for COSE_Encrypted and COSE_Enveloped We would like to refer to "detached content" also for these other structures In practice, t would be enough to simply write: "If the payload is transported separately **(ie detached content)**, then a nil CBOR object is placed in this location and it is the responsibility of the application to ensure that it will be transported without changes" in section 41 and 61 --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/58 ----==_mimepart_56a1f3db95e5a_7fc53ffb06e3d2bc2192966 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Could you add a definition of "detached content" for (at least) COSE_Sign1 and COSE_Mac0? Right now detached content is mentioned in the draft only for COSE_Encrypted and COSE_Enveloped We would like to refer to "detached content" also for these other structures

In practice, t would be enough to simply write:
"If the payload is transported separately (ie detached content), then a nil CBOR object is placed in this location and it is the responsibility of the application to ensure that it will be transported without changes"
in section 41 and 61

—
Reply to this email directly or view it on GitHub.

----==_mimepart_56a1f3db95e5a_7fc53ffb06e3d2bc2192966-- From nobody Sat Jan 23 05:23:33 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043A51A036C for ; Sat, 23 Jan 2016 05:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=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 23soK4vuu9Vt for ; Sat, 23 Jan 2016 05:23:30 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95DA61A0369 for ; Sat, 23 Jan 2016 05:23:30 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id x1so39011243qkc.1 for ; Sat, 23 Jan 2016 05:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=lKmaJ+520eVDn8ESw9OwVeNvll2XCs9o7FSElQdfRZE=; b=IIKBPItPhd7h8JoTzfezpPen1+HCU5cu/uGJReBHNep6YIx8mEmc0H3dvYsPMd+in9 njwrR5UPjET0ejwqdPEpcMucFgEkKe4hdA93w7ozOjYyTuFlfSHE4Nn4hMDHrmkQQC5l Ca7f6vFCKehlg+fMgfjP3FICrPSEj9T0/LRxlkh63YBIBCsQw3DH8kg3K1L7PN9jmLWV 5YAuoKRR9e14ZPEX/OqQ1+eeY6qHfNDVnO860UJbztUZWz4ygP+ht9tJyVr8xaQxkAdr +wbdN1qa7QfG7S1eoExgCZQmJzQwagFE0deVOHMJsQWc//9tpts52Cha9FyRrXxtKZaE 2/iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=lKmaJ+520eVDn8ESw9OwVeNvll2XCs9o7FSElQdfRZE=; b=QLwWUtPL4ySQwitgtvhLQVG+k8CLcOxbSkvPtGA7Mckz6e3w7VaTMlKFTBsCXtka43 BIdpXrhJs6neGcR0uXO4PzaLkVUtlJnTdwFAHvKa5ZfY4X7QZlsfaqqn8rBbVw1GCj7S TyaGIZIcuw6cRXNG3hHXN+ZGoNq+mC7qrNRd0dPUuNaLy3CJ8eDgFoV3Ds9RwK3axSVU EousVNPO+X37qxvX/6PWxaQvS0ndvmcdVPTneaQWL8yEeFm86HljAuAsvu24i5dKxx/U 1ZNiIQhhaxQ1ZDPNzExjy48/xRqkhfBjrLc1kTB2k5dcwHwuay6AzA4XCSl9OBxe2sNz aljA== X-Gm-Message-State: AG10YOTtc0YoIFw8m5vtdGb1ZoNx+gyvl7qZNUr7SCl7R2nnfNbomOrEZCA6bKXxUYSpmV2dwcBULqrw/GEclg== MIME-Version: 1.0 X-Received: by 10.55.24.77 with SMTP id j74mr9665155qkh.53.1453555409388; Sat, 23 Jan 2016 05:23:29 -0800 (PST) Received: by 10.55.179.1 with HTTP; Sat, 23 Jan 2016 05:23:29 -0800 (PST) Date: Sat, 23 Jan 2016 14:23:29 +0100 Message-ID: From: Samuel Erdtman To: cose , Jim Schaad , Ace@ietf.org, =?UTF-8?Q?Erik_Wahlstr=C3=B6m?= Content-Type: multipart/alternative; boundary=001a11440d3ad6aa42052a003db5 Archived-At: Subject: [COSE] CoAP Content-Format X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 13:23:32 -0000 --001a11440d3ad6aa42052a003db5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I=C2=B4m writing on the draft-ietf-ace-oauth-authz and came to the point wh= ere I need a Content-Format for conveying the PoP token from the Client to the Resource Server as content of a CoAP POST. draft-ietf-ace-oauth-authz does not mandate use of COSE encoded tokens but it seems reasonable, I could use application/cbor but application/cose, application/cose+cwt or application/cwt seems more appropriate. Are there plans to register any of these Content-Format either from the COSE specification or the CWT specification or should I do something from draft-ietf-ace-oauth-authz? Best Regards //Samuel --001a11440d3ad6aa42052a003db5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I=C2=B4m writing on the=C2=A0draft-= ietf-ace-oauth-authz and came to the point where I need a=C2=A0Content-Form= at for conveying the PoP token from the Client to the Resource Server as co= ntent of a CoAP POST.

draft-ietf-ace-oauth-authz d= oes not mandate use of COSE encoded tokens but it seems reasonable, I could= use=C2=A0applicati= on/cbor but=C2=A0application/cose,=C2=A0application/cose+cwt or=C2=A0application/cwt seems more=C2=A0appropriate.
Are t= here plans to register any of these=C2=A0Content-Format either from the COSE specification or the CW= T specification or should I do something from=C2=A0=C2=A0draf= t-ietf-ace-oauth-authz?

Best Regards
//S= amuel
=C2= =A0
--001a11440d3ad6aa42052a003db5-- From nobody Sat Jan 23 09:10:18 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DC31B39B0; Sat, 23 Jan 2016 09:10:15 -0800 (PST) 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 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 SlXuoPcOw95Q; Sat, 23 Jan 2016 09:10:14 -0800 (PST) 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 E78EB1B3993; Sat, 23 Jan 2016 09:10:13 -0800 (PST) Received: from mfilter30-d.gandi.net (mfilter30-d.gandi.net [217.70.178.161]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 4E72E1720B2; Sat, 23 Jan 2016 18:10:12 +0100 (CET) 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 TgSnssUHcFZz; Sat, 23 Jan 2016 18:10:10 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id AD60D172098; Sat, 23 Jan 2016 18:10:09 +0100 (CET) Message-ID: <56A3B3F2.7070003@tzi.org> Date: Sat, 23 Jan 2016 18:10:10 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Samuel Erdtman References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Jim Schaad , Ace@ietf.org, =?UTF-8?B?RXJpayBXYWhsc3Ryw7Zt?= , cose Subject: Re: [COSE] CoAP Content-Format X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 17:10:16 -0000 > I´m writing on the draft-ietf-ace-oauth-authz and came to the point > where I need a Content-Format for conveying the PoP token from the > Client to the Resource Server as content of a CoAP POST. > > draft-ietf-ace-oauth-authz does not mandate use of COSE encoded tokens > but it seems reasonable, I could use application/cbor > but application/cose, application/cose+cwt or application/cwt seems > more appropriate. Once a COSE-based OAuth token is defined, that should get a media type and a do a CoAP content-format registration right with that. There is a bit of structure behind the +xyz names, so here this would be: application/cwt+cbor (but then, because of the signing, there is little point in having anything but a cbor version of that, so the +cbor is a bit redundant). > Are there plans to register any of these Content-Format either from the > COSE specification or the CWT specification or should I do something > from draft-ietf-ace-oauth-authz? Whoever gets to define the media type (format, contents, processing rules) gets to register it. Is this a CWT? Are we done with deciding which WG does CWT? Grüße, Carsten From nobody Sat Jan 23 13:36:17 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D221A8842; Sat, 23 Jan 2016 13:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 uqs1zTp-zFFK; Sat, 23 Jan 2016 13:36:12 -0800 (PST) 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 6B7D91A039B; Sat, 23 Jan 2016 13:36:12 -0800 (PST) Received: from hebrews (unknown [50.45.239.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 6C9A52C9B7; Sat, 23 Jan 2016 13:36:11 -0800 (PST) From: "Jim Schaad" To: "'Samuel Erdtman'" , "'cose'" , , =?UTF-8?Q?'Erik_Wahlstr=C3=B6m'?= References: In-Reply-To: Date: Sat, 23 Jan 2016 13:33:35 -0800 Message-ID: <03c601d15625$b7771b30$26655190$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03C7_01D155E2.A955AFF0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQGaZk8iigNlBXuxIZmAU2Qd7Bpl0Z93fpvg Archived-At: Subject: Re: [COSE] CoAP Content-Format X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 21:36:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03C7_01D155E2.A955AFF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The COSE document registers application/cose but not = application/cose+cbor. I don=E2=80=99t know the status of CWT. =20 Jim =20 =20 From: Samuel Erdtman [mailto:samuel@erdtman.se]=20 Sent: Saturday, January 23, 2016 5:23 AM To: cose ; Jim Schaad ; = Ace@ietf.org; Erik Wahlstr=C3=B6m Subject: CoAP Content-Format =20 Hi, =20 I=C2=B4m writing on the draft-ietf-ace-oauth-authz and came to the point = where I need a Content-Format for conveying the PoP token from the = Client to the Resource Server as content of a CoAP POST. =20 draft-ietf-ace-oauth-authz does not mandate use of COSE encoded tokens = but it seems reasonable, I could use application/cbor but = application/cose, application/cose+cwt or application/cwt seems more = appropriate. Are there plans to register any of these Content-Format either from the = COSE specification or the CWT specification or should I do something = from draft-ietf-ace-oauth-authz? =20 Best Regards //Samuel =20 ------=_NextPart_000_03C7_01D155E2.A955AFF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The COSE document registers application/cose but not = application/cose+cbor.=C2=A0 I don=E2=80=99t know the status of = CWT.

 

Jim

 

 

From:<= /b> = Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Saturday, = January 23, 2016 5:23 AM
To: cose <cose@ietf.org>; Jim = Schaad <ietf@augustcellars.com>; Ace@ietf.org; Erik Wahlstr=C3=B6m = <erik@wahlstromstekniska.se>
Subject: CoAP = Content-Format

 

Hi,

 

I=C2=B4m writing on = the draft-ietf-ace-oauth-authz and came to the point where I need = a Content-Format for conveying the PoP token from the Client to the = Resource Server as content of a CoAP POST.

 

draft-ietf-ace-oauth-authz does not mandate use of = COSE encoded tokens but it seems reasonable, I could use application/cbor but application/cose, application/cose+cwt = or application/cwt seems = more appropriate.

Are there plans to register any of these Content-Format either = from the COSE specification or the CWT specification or should I do = something = from  draft-ietf-ace-oauth-authz?

 

Best Regards

//Samuel

 

------=_NextPart_000_03C7_01D155E2.A955AFF0-- From nobody Sun Jan 24 13:29:23 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6C31B333C for ; Sun, 24 Jan 2016 13:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 mmz8Gbgn6jha for ; Sun, 24 Jan 2016 13:29:19 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id C8DCD1B333D for ; Sun, 24 Jan 2016 13:29:16 -0800 (PST) X-AuditID: 12074422-f79c46d000006aa7-19-56a5422bc009 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 dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 38.DB.27303.B2245A65; Sun, 24 Jan 2016 16:29:15 -0500 (EST) 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 u0OLTEIN011511; Sun, 24 Jan 2016 16:29:15 -0500 Received: from [192.168.128.48] (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 u0OLTA5o015649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 24 Jan 2016 16:29:12 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <020a01d154a3$73413230$59c39690$@augustcellars.com> Date: Sun, 24 Jan 2016 16:29:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <810F0B8E-5693-42DA-97CA-B2F757A092E6@mit.edu> References: <021801d14e83$58d1c5c0$0a755140$@augustcellars.com> <5698B63F.6060007@tzi.org> <020a01d154a3$73413230$59c39690$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixG6noqvttDTM4OBOC4sjU+6yWkzbOpXV YuWkHewWq6d/Z3Ng8dg4Zzqbx5IlP5k8ln99wOIxbVFmAEsUl01Kak5mWWqRvl0CV8b373cY CxolK37+mcHawLhPuIuRk0NCwETi4aZXjBC2mMSFe+vZuhi5OIQEFjNJ3Gx6COVsZJRoP/kP yrnNJPHz/BR2kBZmAXWJP/MuMYPYvAJ6Eq9uXWYFsYUFrCSW/ngAVsMmoCoxf+UtJhCbU8BB 4seHFWA2C1B8+sepTBBzoiSWLWyBmqkNZL+GmmklceHKAkaIxZsZJf5/esUCkhABWrx19U0m iLtlJXb/fsQ0gVFwFpKbZiG5aRaSuQsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpmurlZpbo paaUbmIEh7qL0g7GnweVDjEKcDAq8fBaqC0NE2JNLCuuzD3EKMnBpCTKWyUHFOJLyk+pzEgs zogvKs1JLT7EKMHBrCTCG2EElONNSaysSi3Kh0lJc7AoifPu6pgbJiSQnliSmp2aWpBaBJOV 4eBQkuDNdgBqFCxKTU+tSMvMKUFIM3FwggznARpeBVLDW1yQmFucmQ6RP8Woy3Fs7o21TEIs efl5qVLivEEgRQIgRRmleXBzQCkq4e1h01eM4kBvCfNuAqniAaY3uEmvgJYwAS35q7kYZElJ IkJKqoHRyrd0857V6x+YtKySPzqd5+3TkyuPnWE3NVq5OrtEvtPtLU/dwWWXmB+oFoU+nlXz 0+m9uvQcxusMyvyXF1++oG+88Pjfb0YuhcbTN3zqnml359FRGb2eqTM+7lrz6Y0G+8+N62P/ KB86+Ndm4be5Gt8vOuzo3jGvfF/Qpy/hi08npvsxvuOqUlZiKc5INNRiLipOBAABn4efLAMA AA== Archived-At: Cc: Carsten Bormann , Derek Atkins , cose@ietf.org Subject: Re: [COSE] Issue - Change the definition of label X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 21:29:21 -0000 The chairs have discussed the issue in this thread. There seems to be = almost equal support for both aspects, with a rough preference for = allowing strings to aid in certain scenarios, particularly development = and debugging. As such the chairs have decided to continue to allow = strings as labels. More specifically, to allow the uint/sint/tstring = data type as defined currently.=20 The argument against having this is one of code complexity, which we = certainly hear. Therefore, if those who would like to see the label = simplified can demonstrate the difference in code complexity overhead = cased by this decision, with actual concrete COSE code to compare, then = the working group can reconsider.=20 Thank you all for the discussion,=20 =E2=80=94 Justin & Kepeng, your COSE Chairs .-=3D=3D=3D-. | . . | | .'. | ()_____() ||_____|| jgs W W > On Jan 21, 2016, at 6:28 PM, Jim Schaad = wrote: >=20 > You are not too late to weigh in on this issue, however you have made = it impossible for me to say that there is a consensus one way or the = other on it. There is basically an even split. >=20 > Chairs can you please weight in? >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: Derek Atkins [mailto:derek@ihtfp.com] >> Sent: Thursday, January 21, 2016 8:21 AM >> To: Carsten Bormann >> Cc: Jim Schaad ; cose@ietf.org >> Subject: Re: [COSE] Issue - Change the definition of label >>=20 >> Hi >>=20 >> Carsten Bormann writes: >>=20 >>> The main reason to have string labels is to make it easier to >>> coordinate label use in the experimental, pre-registration phase. >>> More JSONy, and all that. >>>=20 >>> We could instead adopt a convention of goedelizing those strings = into >>> numbers. >>> To give a real-world example for that: one CBOR tag was registered >>> with the number 22098. >>> That is 0x5652, or "RV" when read in a hex dump in LSB order (it is = a >>> tag for Perl "Reference Value"). Makes debugging from a hex dump >>> slightly easier... >>> Of course, that only works well for 1, 2, 4, or 8 byte strings. >>=20 >> Coming at this a week later, but I'm with Carsten. I think allowing = string labels >> (in general) is extremely useful for extension prototyping, or for = making >> "private-use" data structures that could have a low probability of = clashing with >> someone else's private-use label. >>=20 >> I'll note that the code required to support all three data types >> (sint/uint/tstring) is NOT significant, and frankly IMHO it does not = add much >> complexity. >>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> -derek >> -- >> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >> Member, MIT Student Information Processing Board (SIPB) >> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >> warlord@MIT.EDU PGP key available >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Sun Jan 24 16:52:50 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE7A1B364A; Sun, 24 Jan 2016 16:52:48 -0800 (PST) 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 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 ckQ9JiW8amkA; Sun, 24 Jan 2016 16:52:47 -0800 (PST) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE2F1B3648; Sun, 24 Jan 2016 16:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1453683163; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=kOMamCs/HSIqOEIy7zmLg8Y1AAYuu1u/Pwh+neZOGjU=; b=N7j9g/2DwkhLCIq5D0gHB/4YiQCohRHi4gDm9EZSW7j0XEGGEumZfcWpdBUIG9hXRG/jo3Nu1ECutjHwSC8p/XzhFFFYgDSMOZB48QVA/rm5cVFR8m1x7x87qbsR6if623bKjR92zan6pqldprxj8vB1VlaJGu3JEcn3Pvni98o= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R591e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01l10434; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=6; SR=0; TI=SMTPD_----4Tr-Ofd_1453683153; Received: from 30.10.27.169(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.105) by smtp.aliyun-inc.com(127.0.0.1); Mon, 25 Jan 2016 08:52:40 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Mon, 25 Jan 2016 08:52:36 +0800 From: "Kepeng Li" To: Carsten Bormann , Samuel Erdtman Message-ID: Thread-Topic: [COSE] CoAP Content-Format References: <56A3B3F2.7070003@tzi.org> In-Reply-To: <56A3B3F2.7070003@tzi.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: Jim Schaad , Erik =?ISO-8859-1?B?V2FobHN0cvZt?= , cose , Ace@ietf.org Subject: Re: [COSE] CoAP Content-Format X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 00:52:48 -0000 > Are we done with deciding which WG does CWT? Yes, it should be done in ACE WG. Please refer to the discussions in COSE mailing list: http://www.ietf.org/mail-archive/web/cose/current/msg00810.html Kind Regards Kepeng =E5=9C=A8 24/1/16 1:10 am=EF=BC=8C "Carsten Bormann" =E5=86=99=E5=85=A5: >> I=C2=B4m writing on the draft-ietf-ace-oauth-authz and came to the point >> where I need a Content-Format for conveying the PoP token from the >> Client to the Resource Server as content of a CoAP POST. >>=20 >> draft-ietf-ace-oauth-authz does not mandate use of COSE encoded tokens >> but it seems reasonable, I could use application/cbor >> but application/cose, application/cose+cwt or application/cwt seems >> more appropriate. > >Once a COSE-based OAuth token is defined, that should get a media type >and a do a CoAP content-format registration right with that. > >There is a bit of structure behind the +xyz names, so here this would be: > >application/cwt+cbor > >(but then, because of the signing, there is little point in having >anything but a cbor version of that, so the +cbor is a bit redundant). > >> Are there plans to register any of these Content-Format either from the >> COSE specification or the CWT specification or should I do something >> from draft-ietf-ace-oauth-authz? > >Whoever gets to define the media type (format, contents, processing >rules) gets to register it. Is this a CWT? Are we done with deciding >which WG does CWT? > >Gr=C3=BC=C3=9Fe, Carsten > >_______________________________________________ >COSE mailing list >COSE@ietf.org >https://www.ietf.org/mailman/listinfo/cose From nobody Mon Jan 25 02:52:44 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627C01A89FB for ; Mon, 25 Jan 2016 02:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=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 hg0-jRzJIiUP for ; Mon, 25 Jan 2016 02:52:40 -0800 (PST) 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 C61341A89F9 for ; Mon, 25 Jan 2016 02:52:39 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id m198so82071511lfm.0 for ; Mon, 25 Jan 2016 02:52:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wahlstromstekniska-se.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8pf/DVadmVQubbb/OK8qozbwde5P7yuDnxdi3R+nU9s=; b=Ii9iaEWDRo/hb9xv0l4lx8MXGC0Qk2LbCOOFteeYkgSfn+90FVEsoZwRQBADxOcuJ9 sfSHOuDBwp67UbFdRH5D6Jdk4y5W6VEdXOHHQKaXvtyGVi0EW80xmgaPNwsXBIdIg1Qj 1mXtsJiSO4s2/wZwuJhSAPetnGczlUpx62pX81WEnega3ZL7kadkcBC6HmWe023LlZ// eMkYm40EgDuzYxtkP8AF9FBcAN7OKRYyytOxXK+mj9p4dI1NgRjNlAUHKUP4WD8yu9gB uwdNL95K//+mllp9McuYQSKN4d0QSpFCxaHeUcWtgIHGfqo67qM7Fwro8TsQKwy05xTH nisg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8pf/DVadmVQubbb/OK8qozbwde5P7yuDnxdi3R+nU9s=; b=XL02rAdKB0wwPI0Ngya9gUC9f880ZrOU644ZurJs8U9wuzmIqPfw2xfhM1uai8Fyvh +q0TYL1upIA6A9QNK6kGepPB9jpULn9TZ+Evndo1VBEBxUrLL3GFAkzTMXy24r3U0rBS 0dS7MWAF4rPQ207EPFV3hVRQ9XZEuXbCVfpoG/9b3md4ez3CVPtCZYi+3HfSHe/QYo+R 1tL90R50uEa3l/W0R01doNW1y7U4ZlH+uEAUXmhFhJF0rb9crfTFrGgQzwhE6hUkdcpY oc5mPIoc/37zIlnyT5i6RCEYd5ShVBLKQ/SmnUfnr3yqOd+1NMqZ2pKIebJupcYZC74m 3h9w== X-Gm-Message-State: AG10YOQfVYgt+u5yf/tfUgCRimEhcLmWhp6Jfnov80Pc34XZ4AKCjGoAnCnDevVwQKNbnQ== X-Received: by 10.25.207.3 with SMTP id f3mr6368621lfg.20.1453719157650; Mon, 25 Jan 2016 02:52:37 -0800 (PST) Received: from [192.168.1.10] (37-247-26-197.customers.ownit.se. [37.247.26.197]) by smtp.gmail.com with ESMTPSA id dt9sm2550026lbc.47.2016.01.25.02.52.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 02:52:35 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F01EC0C5-A61D-445F-A0AC-5BDE9636300F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: =?utf-8?Q?Erik_Wahlstr=C3=B6m?= In-Reply-To: Date: Mon, 25 Jan 2016 11:52:34 +0100 Message-Id: <1059B572-516A-4454-B4FE-B2A8A27A871E@wahlstromstekniska.se> References: <56A3B3F2.7070003@tzi.org> To: Kepeng Li X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Samuel Erdtman , Carsten Bormann , cose , Jim Schaad , Ace@ietf.org Subject: Re: [COSE] CoAP Content-Format X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 10:52:42 -0000 --Apple-Mail=_F01EC0C5-A61D-445F-A0AC-5BDE9636300F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Latest version can be found here (in ace): https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/ = The earlier document in oauth2 is archived and also replaced by above = version. I added a potential Content-Format as a new issue in an issue tracker = for CWT. https://github.com/erwah/ietf/issues/7 = / Erik > On 25 Jan 2016, at 01:52, Kepeng Li = wrote: >=20 >> Are we done with deciding which WG does CWT? >=20 >=20 > Yes, it should be done in ACE WG. >=20 > Please refer to the discussions in COSE mailing list: > http://www.ietf.org/mail-archive/web/cose/current/msg00810.html >=20 > Kind Regards > Kepeng >=20 > =E5=9C=A8 24/1/16 1:10 am=EF=BC=8C "Carsten Bormann" = =E5=86=99=E5=85=A5: >=20 >>> I=C2=B4m writing on the draft-ietf-ace-oauth-authz and came to the = point >>> where I need a Content-Format for conveying the PoP token from the >>> Client to the Resource Server as content of a CoAP POST. >>>=20 >>> draft-ietf-ace-oauth-authz does not mandate use of COSE encoded = tokens >>> but it seems reasonable, I could use application/cbor >>> but application/cose, application/cose+cwt or application/cwt seems >>> more appropriate. >>=20 >> Once a COSE-based OAuth token is defined, that should get a media = type >> and a do a CoAP content-format registration right with that. >>=20 >> There is a bit of structure behind the +xyz names, so here this would = be: >>=20 >> application/cwt+cbor >>=20 >> (but then, because of the signing, there is little point in having >> anything but a cbor version of that, so the +cbor is a bit = redundant). >>=20 >>> Are there plans to register any of these Content-Format either from = the >>> COSE specification or the CWT specification or should I do something >>> from draft-ietf-ace-oauth-authz? >>=20 >> Whoever gets to define the media type (format, contents, processing >> rules) gets to register it. Is this a CWT? Are we done with = deciding >> which WG does CWT? >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >=20 >=20 --Apple-Mail=_F01EC0C5-A61D-445F-A0AC-5BDE9636300F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

Latest version can be found here (in = ace):
https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-= token/

The = earlier document in oauth2 is archived and also replaced by above = version.

I = added a potential Content-Format as a new issue in an issue tracker for = CWT.
https://github.com/erwah/ietf/issues/7

/ Erik


On 25 Jan 2016, at 01:52, = Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:

Are we done with deciding which WG does CWT?


Yes, it should be = done in ACE WG.

Please refer to the = discussions in COSE mailing list:
http://www.ietf.org/mail-archive/web/cose/current/msg00810.html=

Kind Regards
Kepeng

=E5=9C=A8 24/1/16 1:10 am=EF=BC=8C "Carsten = Bormann" <cabo@tzi.org> =E5=86=99=E5=85=A5:

I=C2=B4m writing on the draft-ietf-ace-oauth-authz and came = to the point
where I need a Content-Format for conveying = the PoP token from the
Client to the Resource Server as = content of a CoAP POST.

draft-ietf-ace-oauth-authz does not mandate use of COSE = encoded tokens
but it seems reasonable, I could use = application/cbor
but application/cose, = application/cose+cwt or application/cwt seems
more = appropriate.

Once a COSE-based = OAuth token is defined, that should get a media type
and a = do a CoAP content-format registration right with that.

There is a bit of structure behind the +xyz names, so here = this would be:

application/cwt+cbor

(but then, because of the signing, there is = little point in having
anything but a cbor version of = that, so the +cbor is a bit redundant).

Are there plans to = register any of these Content-Format either from the
COSE = specification or the CWT specification or should I do something
from  draft-ietf-ace-oauth-authz?

Whoever gets to define the media = type (format, contents, processing
rules) gets to register = it.  Is this a CWT?  Are we done with deciding
which WG does CWT?

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

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



= --Apple-Mail=_F01EC0C5-A61D-445F-A0AC-5BDE9636300F--