From nobody Wed Feb 3 22:16:21 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 5AD4D1A90FD for ; Wed, 3 Feb 2016 22:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 pw1ANu6KV_9r for ; Wed, 3 Feb 2016 22:16:18 -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 A2F451A90FE for ; Wed, 3 Feb 2016 22:16:18 -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 A898738F26 for ; Wed, 3 Feb 2016 22:16:17 -0800 (PST) From: "Jim Schaad" To: Date: Wed, 3 Feb 2016 22:13:44 -0800 Message-ID: <029401d15f13$3399f480$9acddd80$@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: AdFfDefZ20JtNdeERjC4laGj61RhZg== Archived-At: Subject: [COSE] Issue #51 - make "alg" field optional 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, 04 Feb 2016 06:16:20 -0000 I have been trying to figure out a way forward on this issue that will make all parties happy and I have not been successful. I am therefore going to open this up for discussion to see if it is possible as a group to come up with a solution that will appeal to everybody. I doubt that it is going to be doable. The request in the issue is to relax the current restriction where the alg MUST be present in each message oriented object defined by COSE. There is current a requirement that the item be present and that, if possible, it MUST be in the protected bucket of header items. This requirement is supported in several different security consideration by discussions that the algorithm identifier needs to be included as part of the authenticated data in order to protect against algorithm substation attacks. Different types of attacks that have been envisioned that arise from changing the hash of signatures (see discussion on the CFRG mailing list), shorting the tag of an AEAD algorithm, and attacks changing the RSA algorithm used from PSS or OAEP to v1.5. The first and third attacks have been demonstrated or seen in the real world. The middle case is, in my mind, an extension of the current attacks where CBC tag checking is done poorly and frequently allows for changes in encrypted text to be made. (Currently CBC will correctly decrypt a little bit more often than 1 in 256 times with a modified text.) I have discussed this with the OSCoAP document (https://datatracker.ietf.org/doc/draft-selander-ace-object-security) writers and have suggested that the proper location to change this from a MUST to a don't do this is in their document and that it be accompanied with an appropriate external data structure that would include this field as part of the authenticated data. This would satisfy my very strong desire for the item always be authenticated when possible, with the strong desire on their part to not include the field in the structures that they are looking at. From my point of view, it also restricts the places where this would be done to the subset of structures that they are using and would allow them to address the fact that they requirements may be different, for example, when looking at and Enveloped structures as oppose to an Encrypted structure. The former may require the algorithm be present while the latter might not. One of the main problems that I have with doing a general relaxation, even with the type of text that is suggested in the issue, is that this does not make the application explicitly define what the external data structure will look like in the event it decides to omit the algorithm based on common use rather than based on the specification itself. Forcing this to be done by the application specification makes this be a problem of the application and it would be up to it to define the necessary external data structure at the same time as it relaxes the requirement on the algorithm being present. I am willing to add an appendix to discuss what an application needs to do in order to have this relaxation, but strongly do not want to place this change in the core text. Jim From nobody Wed Feb 3 23:06:04 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 BBB711A0371 for ; Wed, 3 Feb 2016 23:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 9zzd16am4YTW for ; Wed, 3 Feb 2016 23:06:02 -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 BF0381A0370 for ; Wed, 3 Feb 2016 23:06:02 -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 5A32038F11 for ; Wed, 3 Feb 2016 23:06:02 -0800 (PST) From: "Jim Schaad" To: Date: Wed, 3 Feb 2016 23:03:28 -0800 Message-ID: <029c01d15f1a$269e1de0$73da59a0$@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: AdFfGDW2+0YJpoH7TSy4hWQxoefQRQ== Archived-At: Subject: [COSE] Question on RFC 7252 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, 04 Feb 2016 07:06:03 -0000 In section 2.2, these is discussion dealing with figure 5 about how to deal with the case where a server can perform an operation, but it may take a while to do and it does not want the client to continually send it messages or time out waiting for a response. The solution presented requires that a token be present in the original request so that it can be tied to the eventual response message. There does not appear to be any text dealing with the case of a token not being present. What is the proper response to say - ask again but make sure there is a token in the request this time? One could start the request processing and respond with a 5.03 - service unavailable and an estimate of how long it will take to complete the request but that seems wrong some how What is the correct response to give if the separate message cannot be sent anytime soon because the server already has a message in its cache with the message id of the original request? I am assuming, and believe that the text in section 4.4 says that messages ids must be unique for the sender to a specific address so the changes are low unless the server is using a hit cache for multiple recipients. Jim From nobody Wed Feb 3 23:20:58 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 3C7AC1A049A for ; Wed, 3 Feb 2016 23:20:57 -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 mJEzmdq38Oge for ; Wed, 3 Feb 2016 23:20:55 -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 A84D71A033A for ; Wed, 3 Feb 2016 23:20:55 -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 12D5E2CA2C for ; Wed, 3 Feb 2016 23:20:55 -0800 (PST) From: "Jim Schaad" To: References: <029c01d15f1a$269e1de0$73da59a0$@augustcellars.com> In-Reply-To: <029c01d15f1a$269e1de0$73da59a0$@augustcellars.com> Date: Wed, 3 Feb 2016 23:18:21 -0800 Message-ID: <02a601d15f1c$3ab74f70$b025ee50$@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: AQKOSbMWex4lXrLS58daE8SOjMefnJ2hpQbQ Archived-At: Subject: Re: [COSE] Question on RFC 7252 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, 04 Feb 2016 07:20:57 -0000 Sorry - wrong mailing list. > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Wednesday, February 03, 2016 11:03 PM > To: cose@ietf.org > Subject: [COSE] Question on RFC 7252 > > In section 2.2, these is discussion dealing with figure 5 about how to deal with > the case where a server can perform an operation, but it may take a while to do > and it does not want the client to continually send it messages or time out > waiting for a response. The solution presented requires that a token be present > in the original request so that it can be tied to the > eventual response message. There does not appear to be any text dealing > with the case of a token not being present. > > What is the proper response to say - ask again but make sure there is a token in > the request this time? One could start the request processing and respond with > a 5.03 - service unavailable and an estimate of how long it will take to complete > the request but that seems wrong some how > > What is the correct response to give if the separate message cannot be sent > anytime soon because the server already has a message in its cache with the > message id of the original request? I am assuming, and believe that the text in > section 4.4 says that messages ids must be unique for the sender to a specific > address so the changes are low unless the server is using a hit cache for multiple > recipients. > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Thu Feb 4 04:06: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 87DB81B2C67 for ; Thu, 4 Feb 2016 04:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 0gzUMfWpMHKt for ; Thu, 4 Feb 2016 04:06:06 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 669B61B2C66 for ; Thu, 4 Feb 2016 04:06:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 62353401; Thu, 4 Feb 2016 14:06:04 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id Ai0HzxgccHCn; Thu, 4 Feb 2016 14:06:04 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 2B773C4; Thu, 4 Feb 2016 14:06:04 +0200 (EET) Date: Thu, 4 Feb 2016 14:06:02 +0200 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20160204120602.GA17773@LK-Perkele-V2.elisa-laajakaista.fi> References: <029401d15f13$3399f480$9acddd80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <029401d15f13$3399f480$9acddd80$@augustcellars.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] Issue #51 - make "alg" field optional 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, 04 Feb 2016 12:06:08 -0000 On Wed, Feb 03, 2016 at 10:13:44PM -0800, Jim Schaad wrote: > I have been trying to figure out a way forward on this issue that will make > all parties happy and I have not been successful. I am therefore going to > open this up for discussion to see if it is possible as a group to come up > with a solution that will appeal to everybody. I doubt that it is going to > be doable. > > The request in the issue is to relax the current restriction where the alg > MUST be present in each message oriented object defined by COSE. There is > current a requirement that the item be present and that, if possible, it > MUST be in the protected bucket of header items. Thinking what I would think is proper, I would associate the algorithm with the key. Either external key, or contained in protected members of enveloped key. Even putting the algorithm in protected members of the object itself would not protect against all substitution attacks (I think Ed25519 vs. Ed25519ph substitution for instance). In any case, repeating already implicitly known algorithm is good source of security bugs... I haven't thought how much trouble that kind of architecture would cause in COSE... -Ilari From nobody Thu Feb 4 10:55:25 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 D5CAD1ACD76 for ; Thu, 4 Feb 2016 10:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 LEK8Syx-TwxX for ; Thu, 4 Feb 2016 10:55:21 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A0A1ACD54 for ; Thu, 4 Feb 2016 10:55:20 -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=owHThhCchYvUTJ7Ey8zN5hNuIi8lkXr8RqTHm88DGYc=; b=cg366WBeQSsKYxeoI6ujPb+Y5tzVeevU2KHHNU6f/+0kzw5hvLrK+9jSjA7bZlOWJz42Okp0oc5SUtfHY4ZZZlpFMl/K6+/5XFpH7vi2KD7w/jf8bCzogDsWv+IqP3nsNhkmysmxnUmG2oSkBMJJVa9MzyGtxPYExJmJR/W5K4k= 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.396.15; Thu, 4 Feb 2016 18:55:01 +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.0396.020; Thu, 4 Feb 2016 18:55:01 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] Issue #51 - make "alg" field optional Thread-Index: AdFfDefZ20JtNdeERjC4laGj61RhZgAb6VXI Date: Thu, 4 Feb 2016 18:55:01 +0000 Message-ID: References: <029401d15f13$3399f480$9acddd80$@augustcellars.com> In-Reply-To: <029401d15f13$3399f480$9acddd80$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [166.176.184.177] x-ms-office365-filtering-correlation-id: 7ccdc895-90f6-4b77-491e-08d32d94afea x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:KM9hqah8dloF2qOtsuK0pSb/uZI3vIHmlM27Ox1fiP6v5lm7J1zOogbA/VqwQz8XuYob86ZAZbdgTB+kbJLS7gI2OhLPK/jEEXZJUXsBqiHOZFGm433PXuhhM3BsHsAPaft6n8QJHjjtlj22N9oicA==; 24:/lF9yAwihiVbRR4zv0NCeDIqp8t4wGgHMx4sjYDXTmtp3usv/aKuoBZHQTLDn229QE5t5y8BmZdichovUe5v/N2huXUVJ4Ksm3Og71j8qE8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 084285FC5C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(377454003)(5383002)(19580395003)(54356999)(19580405001)(76176999)(66066001)(5001770100001)(122556002)(19617315012)(50986999)(189998001)(107886002)(5001960100002)(5002640100001)(86612001)(3280700002)(3660700001)(86362001)(87936001)(2900100001)(2950100001)(74316001)(2906002)(40100003)(77096005)(15975445007)(19625215002)(99286002)(2501003)(33656002)(11100500001)(3846002)(10400500002)(586003)(10290500002)(5005710100001)(102836003)(6116002)(3900700001)(8990500004)(5008740100001)(5003600100002)(92566002)(5004730100002)(10090500001)(76576001)(16236675004)(1096002)(1220700001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442632BB471FDB13AE37AA9F5D10BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2016 18:55:01.6961 (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: Subject: Re: [COSE] Issue #51 - make "alg" field optional 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, 04 Feb 2016 18:55:25 -0000 --_000_BY2PR03MB442632BB471FDB13AE37AA9F5D10BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable I am against making inclusion of the algorithm optional. Among other reason= s, doing so would make support for crypto agility more problematic. -- Mike ________________________________ From: Jim Schaad Sent: =FD2/=FD3/=FD2016 10:16 PM To: cose@ietf.org Subject: [COSE] Issue #51 - make "alg" field optional I have been trying to figure out a way forward on this issue that will make all parties happy and I have not been successful. I am therefore going to open this up for discussion to see if it is possible as a group to come up with a solution that will appeal to everybody. I doubt that it is going to be doable. The request in the issue is to relax the current restriction where the alg MUST be present in each message oriented object defined by COSE. There is current a requirement that the item be present and that, if possible, it MUST be in the protected bucket of header items. This requirement is supported in several different security consideration b= y discussions that the algorithm identifier needs to be included as part of the authenticated data in order to protect against algorithm substation attacks. Different types of attacks that have been envisioned that arise from changing the hash of signatures (see discussion on the CFRG mailing list), shorting the tag of an AEAD algorithm, and attacks changing the RSA algorithm used from PSS or OAEP to v1.5. The first and third attacks have been demonstrated or seen in the real world. The middle case is, in my mind, an extension of the current attacks where CBC tag checking is done poorly and frequently allows for changes in encrypted text to be made. (Currently CBC will correctly decrypt a little bit more often than 1 in 256 times with a modified text.) I have discussed this with the OSCoAP document (https://datatracker.ietf.org/doc/draft-selander-ace-object-security) writers and have suggested that the proper location to change this from a MUST to a don't do this is in their document and that it be accompanied wit= h an appropriate external data structure that would include this field as par= t of the authenticated data. This would satisfy my very strong desire for the item always be authenticated when possible, with the strong desire on their part to not include the field in the structures that they are looking at. From my point of view, it also restricts the places where this would b= e done to the subset of structures that they are using and would allow them t= o address the fact that they requirements may be different, for example, when looking at and Enveloped structures as oppose to an Encrypted structure. The former may require the algorithm be present while the latter might not. One of the main problems that I have with doing a general relaxation, even with the type of text that is suggested in the issue, is that this does not make the application explicitly define what the external data structure wil= l look like in the event it decides to omit the algorithm based on common use rather than based on the specification itself. Forcing this to be done by the application specification makes this be a problem of the application an= d it would be up to it to define the necessary external data structure at the same time as it relaxes the requirement on the algorithm being present. I am willing to add an appendix to discuss what an application needs to do in order to have this relaxation, but strongly do not want to place this change in the core text. Jim _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose --_000_BY2PR03MB442632BB471FDB13AE37AA9F5D10BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
I am against = making inclusion of the algorithm optional. Among other reasons, doing so w= ould make support for crypto agility more problematic.

-- Mike
From: Jim Schaad
Sent: =FD2/= =FD3/=FD2016 10:16 PM
To: cose@ietf.org
Subject: [COSE= ] Issue #51 - make "alg" field optional

I have been trying to figure out a way forward on = this issue that will make
all parties happy and I have not been successful.  I am therefore goin= g to
open this up for discussion to see if it is possible as a group to come up<= br> with a solution that will appeal to everybody.  I doubt that it is goi= ng to
be doable.

The request in the issue is to relax the current restriction where the alg<= br> MUST be present in each message oriented object defined by COSE.  Ther= e is
current a requirement that the item be present and that, if possible, it MUST be in the protected bucket of header items. 

This requirement is supported in several different security consideration b= y
discussions that the algorithm identifier needs to be included as part of the authenticated data in order to protect against algorithm substation
attacks.  Different types of attacks that have been envisioned  t= hat arise
from changing the hash of signatures (see discussion on the CFRG mailing list), shorting the tag of an AEAD algorithm, and attacks changing the RSA<= br> algorithm used from PSS or OAEP to v1.5. The first and third attacks have been demonstrated or seen in the real world.  The middle case is, in m= y
mind, an extension of the current attacks where CBC tag checking is done poorly and frequently allows for changes in encrypted text to be made.
(Currently CBC will correctly decrypt a little bit more often than 1 in 256=
times with a modified text.)

I have discussed this with the OSCoAP document
(https://datatracker.ietf.org/doc/draft-selander-ace-object-security)
writers and have suggested that the proper location to change this from a MUST to a don't do this is in their document and that it be accompanied wit= h
an appropriate external data structure that would include this field as par= t
of the authenticated data.   This would satisfy my very strong de= sire for
the item always be authenticated when possible, with the strong desire on their part to not include the field in the structures that they are looking=
at.  From my point of view, it also restricts the places where this wo= uld be
done to the subset of structures that they are using and would allow them t= o
address the fact that they requirements may be different, for example, when=
looking at and Enveloped structures as oppose to an Encrypted structure. The former may require the algorithm be present while the latter might not.=

One of the main problems that I have with doing a general relaxation, even<= br> with the type of text that is suggested in the issue, is that this does not=
make the application explicitly define what the external data structure wil= l
look like in the event it decides to omit the algorithm based on common use=
rather than based on the specification itself.  Forcing this to be don= e by
the application specification makes this be a problem of the application an= d
it would be up to it to define the necessary external data structure at the=
same time as it relaxes the requirement on the algorithm being present.

I am willing to add an appendix to discuss what an application needs to do<= br> in order to have this relaxation, but strongly do not want to place this change in the core text.

Jim


_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org= /mailman/listinfo/cose
 --_000_BY2PR03MB442632BB471FDB13AE37AA9F5D10BY2PR03MB442namprd_-- From nobody Fri Feb 5 03:04: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 C09CD1A1BB3 for ; Fri, 5 Feb 2016 03:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 gz1n_ORzvdf8 for ; Fri, 5 Feb 2016 03:04:04 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E4A1A1BB0 for ; Fri, 5 Feb 2016 03:04:03 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-c2-56b481a16530 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D1.C7.05041.1A184B65; Fri, 5 Feb 2016 12:04:01 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.247]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Fri, 5 Feb 2016 12:04:01 +0100 From: Francesca Palombini To: Jim Schaad , "cose@ietf.org" Thread-Topic: Re: [COSE] Issue #51 - make "alg" field optional Thread-Index: AdFgBN84NfHY9LLXS22lKmASYuOyag== Date: Fri, 5 Feb 2016 11:03:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D2736FF6C4A3F3428982D3508DD478DE10150689ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7h+7Cxi1hBhcvaVtM2zqV1WL19O9s DkweG+dMZ/NYsuQnUwBTFJdNSmpOZllqkb5dAlfG5/MzWArem1Uc2/SLtYGxRb+LkZNDQsBE 4s7BZUwQtpjEhXvr2boYuTiEBA4zShw/c4sRwlnMKLFl+k8WkCo2ARuJCw/fs4LYIgIeErt2 f2IGsYUFLCXmndzIDhG3k/jZ8Z4RwtaTmLx4A9gGFgEViYfzz7OB2LwCvhJLr6wCm8kItPn7 qTVgNcwC4hK3nsyHukhAYsme88wQtqjEy8f/WCFsRYmr05dD1edLLHx/nxlipqDEyZlPWCYw Cs1CMmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkbR4tTi4tx0IyO91KLM 5OLi/Dy9vNSSTYzASDm45bfVDsaDzx0PMQpwMCrx8H64vjlMiDWxrLgy9xCjBAezkgjv09It YUK8KYmVValF+fFFpTmpxYcYpTlYlMR51zivDxMSSE8sSc1OTS1ILYLJMnFwSjUwTnDRN6i8 tzihMqe/z1YqeJPvh7A/be/rLzy66Db3a+EWxZ2BAspafq0ad7bc76jmDNnvWiDJ6hEcfrng Q+q9wHUW1T/e9ax2/nvOa66USaWB6oRd4R8yv29jtFec/iKx7vnlRvdzTkrPp0eka7IU+BpW /+Iy5rfz3JQglKy66fhWTnvRxGtKLMUZiYZazEXFiQB1fxeBkAIAAA== Archived-At: Subject: Re: [COSE] Issue #51 - make "alg" field optional 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, 05 Feb 2016 11:04:07 -0000 --_000_D2736FF6C4A3F3428982D3508DD478DE10150689ESESSMB205erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim and all, We are not against having this relaxation discussed in an appendix instead = of in the core of the draft, as long as it is in the COSE document. We will= define in (the next version of) OSCOAP exactly how the external_aad is con= structed (and that it includes alg). Between your choices, we would prefer to have the discussion about optional= alg in an appendix of the COSE draft (that we can refer to) rather than de= fining it ourselves in the OSCOAP draft. Defining the alg to be optional in= OSCOAP while having it mandatory in COSE would create a discrepancy betwee= n the two documents, and I believe it would create confusion for future imp= lementers. I understand you do not want to leave the door open for misinterpretation, = and prefer to have a strong "default" behavior that cannot be misunderstood= and would not create security issues derived by "common use" ; on the othe= r hand I don't understand how could the sentence "either you include the al= gorithm in the (protected part of the) message or in the externally supplie= d aad" be misunderstood. Why wouldn't the restriction "no alg --> alg in ex= ternal_aad" be enough in the COSE document, leaving the task to exactly def= ine the external_aad to the application? I am confused here because it looks to me as if you would rather accept dis= crepancies between COSE and application spec rather than mandate that "the = alg must be included in the external_aad". In my opinion the first would cr= eate more confusion than the second. But I'm interested in hearing the opi= nion of the group of course. tl;dr we (OSCOAP) agree with having this in an appendix if your prefer. Won= dering why mandating alg in external_aad wouldn't be "explicit enough". Francesca --_000_D2736FF6C4A3F3428982D3508DD478DE10150689ESESSMB205erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim and all,

 

We are not against having this = relaxation discussed in an appendix instead of in the core of the draft, as= long as it is in the COSE document. We will define in (the next version of= ) OSCOAP exactly how the external_aad is constructed (and that it includes alg).

 

Between your choices, we would = prefer to have the discussion about optional alg in an appendix of the COSE= draft (that we can refer to) rather than defining it ourselves in the OSCO= AP draft. Defining the alg to be optional in OSCOAP while having it mandatory in COSE would create a discrepancy bet= ween the two documents, and I believe it would create confusion for future = implementers.

 

I understand you do not want to= leave the door open for misinterpretation, and prefer to have a strong = 220;default” behavior that cannot be misunderstood and would not crea= te security issues derived by “common use” ; on the other hand I don’t understand how could the sentence “eith= er you include the algorithm in the (protected part of the) message or in t= he externally supplied aad” be misunderstood. Why wouldn’t the = restriction “no alg --> alg in external_aad” be enough in the COSE document, leaving the task to exactly define the external_aad to = the application?

 

I am confused here because it l= ooks to me as if you would rather accept discrepancies between COSE and app= lication spec rather than mandate that “the alg must be included in t= he external_aad”. In my opinion the first would create more confusion than the second.  But I’m intereste= d in hearing the opinion of the group of course.

 

tl;dr we (OSCOAP) agree with ha= ving this in an appendix if your prefer. Wondering why mandating alg in ext= ernal_aad wouldn’t be “explicit enough”.

 

Francesca

--_000_D2736FF6C4A3F3428982D3508DD478DE10150689ESESSMB205erics_-- From nobody Fri Feb 5 13:40: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 E4E2A1B2D1A for ; Fri, 5 Feb 2016 13:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 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, J_CHICKENPOX_22=0.6] 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 OcKwUwP_icEz for ; Fri, 5 Feb 2016 13:40:40 -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 7CAD81B2D09 for ; Fri, 5 Feb 2016 13:40:40 -0800 (PST) Received: by mail-qg0-x236.google.com with SMTP id b35so78445748qge.0 for ; Fri, 05 Feb 2016 13:40:40 -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=aFUAE7OrxnHxwfGGxZoLRPZaZoo1bpOM4qkzvrdHeBk=; b=LkcdYwW+IShWQ075ctDgXxllgjho4H4zOwP03Hrw9jalRWHoKMpEuu20UY9FvwaLgE y9Y4xTAnd6uPogR/zrR8bA6AbXqn90ryRs+7QVJJr38rjjWNxkxrb3flOpF1wL2dITZ2 1EFE6Q708lla6hPBx9m3lA5+r0JeJ6BmANAQgansXU6cH0QbGZeShOLSCu6bTNTeh+s5 wHijap7vIs1cmHhIcqRtSANtdpcECbJoB6RJtft+7HZB7euOQB4rmdMMGfVBNigKfaNh ZaAHG4ArnHjMrsnfFpoDC6mvzWNW1Qq/wuiSVWLUktM2iKLRiOTSCeoCC8UnM3MT/gR7 W5WA== 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=aFUAE7OrxnHxwfGGxZoLRPZaZoo1bpOM4qkzvrdHeBk=; b=f7lQcRfCIEkKA5hLEorlHGaXdQQlCFpgQgFx0g4wdy4dQ03mh4F1lyiYVKFfMl2iiB DA+GiHR6CrLX0YBKG0kJPSIdT5qhv1EXkgGj8cQ9Lvjq3e12uaRklRE9odZDlWUn32JH ipuSbECWzT/ql1TNaMJkSYNvtN+6Jx8wzgnge7HSVobtoyC9PGF+pfnOMT4VBz5+IqyS mQKj3nZn/nLVkDXxbbdp4UfswgadbDxi5r4pMLYdbHhwS23YRx8hX9Ko+SOTuIRDYxMu Ml3qs6Vz+Xl8I0WPVPbZc192DEqFIqJc9id87H0tSsNXR6itHEbfPA0Ys05rHfwTMUFk hr7g== X-Gm-Message-State: AG10YOQMpUFpUqvL/HxLwcu/dzD4YDAh146UIIXWIlB6PcliYwIc9hGCDHAE8IGFKqjBf1eyBR8ng8d4/111Xw== MIME-Version: 1.0 X-Received: by 10.140.96.245 with SMTP id k108mr20069068qge.31.1454708439529; Fri, 05 Feb 2016 13:40:39 -0800 (PST) Received: by 10.55.179.1 with HTTP; Fri, 5 Feb 2016 13:40:39 -0800 (PST) In-Reply-To: References: Date: Fri, 5 Feb 2016 22:40:39 +0100 Message-ID: From: Samuel Erdtman To: Francesca Palombini Content-Type: multipart/alternative; boundary=001a113b9ce4ca71f1052b0cb303 Archived-At: Cc: Jim Schaad , "cose@ietf.org" Subject: Re: [COSE] Issue #51 - make "alg" field optional 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, 05 Feb 2016 21:40:45 -0000 --001a113b9ce4ca71f1052b0cb303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Francesca and all, I might have missed some previous discussion but I don=C2=B4t get why it is better to have the alg parameter in external_aad than as part of the COSE message. When I read your reply I interpret it as, alg is mandatory, but you are allowed to put it in the COSE message or in the external_aad. What benefit am I missing? Regards //Samuel On Fri, Feb 5, 2016 at 12:03 PM, Francesca Palombini < francesca.palombini@ericsson.com> wrote: > Hi Jim and all, > > > > We are not against having this relaxation discussed in an appendix instea= d > of in the core of the draft, as long as it is in the COSE document. We wi= ll > define in (the next version of) OSCOAP exactly how the external_aad is > constructed (and that it includes alg). > > > > Between your choices, we would prefer to have the discussion about > optional alg in an appendix of the COSE draft (that we can refer to) rath= er > than defining it ourselves in the OSCOAP draft. Defining the alg to be > optional in OSCOAP while having it mandatory in COSE would create a > discrepancy between the two documents, and I believe it would create > confusion for future implementers. > > > > I understand you do not want to leave the door open for misinterpretation= , > and prefer to have a strong =E2=80=9Cdefault=E2=80=9D behavior that canno= t be misunderstood > and would not create security issues derived by =E2=80=9Ccommon use=E2=80= =9D ; on the other > hand I don=E2=80=99t understand how could the sentence =E2=80=9Ceither yo= u include the > algorithm in the (protected part of the) message or in the externally > supplied aad=E2=80=9D be misunderstood. Why wouldn=E2=80=99t the restrict= ion =E2=80=9Cno alg --> > alg in external_aad=E2=80=9D be enough in the COSE document, leaving the = task to > exactly define the external_aad to the application? > > > > I am confused here because it looks to me as if you would rather accept > discrepancies between COSE and application spec rather than mandate that > =E2=80=9Cthe alg must be included in the external_aad=E2=80=9D. In my opi= nion the first > would create more confusion than the second. But I=E2=80=99m interested = in hearing > the opinion of the group of course. > > > > tl;dr we (OSCOAP) agree with having this in an appendix if your prefer. > Wondering why mandating alg in external_aad wouldn=E2=80=99t be =E2=80=9C= explicit enough=E2=80=9D. > > > > Francesca > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > --001a113b9ce4ca71f1052b0cb303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Francesca and all,

I might have miss= ed some previous discussion but I don=C2=B4t get why it is better to have t= he alg parameter in=C2=A0external_aad than as part of the COSE message. When I read= your reply I interpret it as, alg is mandatory, but you are allowed to put= it in the COSE message or in the=C2=A0external_aad. What benefit am I missi= ng?

Regards
//Samuel


=
On Fri, Feb 5, 2016 at 12:03 PM, Francesca P= alombini <francesca.palombini@ericsson.com> w= rote:

Hi Jim and all,

=C2=A0

We are not against having this = relaxation discussed in an appendix instead of in the core of the draft, as= long as it is in the COSE document. We will define in (the next version of= ) OSCOAP exactly how the external_aad is constructed (and that it includes alg).

=C2=A0

Between your choices, we would = prefer to have the discussion about optional alg in an appendix of the COSE= draft (that we can refer to) rather than defining it ourselves in the OSCO= AP draft. Defining the alg to be optional in OSCOAP while having it mandatory in COSE would create a discrepancy bet= ween the two documents, and I believe it would create confusion for future = implementers.

=C2=A0

I understand you do not want to= leave the door open for misinterpretation, and prefer to have a strong =E2= =80=9Cdefault=E2=80=9D behavior that cannot be misunderstood and would not = create security issues derived by =E2=80=9Ccommon use=E2=80=9D ; on the other hand I don=E2=80=99t understand how could the sentence =E2=80=9C= either you include the algorithm in the (protected part of the) message or = in the externally supplied aad=E2=80=9D be misunderstood. Why wouldn=E2=80= =99t the restriction =E2=80=9Cno alg --> alg in external_aad=E2=80=9D be= enough in the COSE document, leaving the task to exactly define the external_aad to = the application?

=C2=A0

I am confused here because it l= ooks to me as if you would rather accept discrepancies between COSE and app= lication spec rather than mandate that =E2=80=9Cthe alg must be included in= the external_aad=E2=80=9D. In my opinion the first would create more confusion than the second.=C2=A0 But I=E2=80=99m interes= ted in hearing the opinion of the group of course.

=C2=A0

tl;dr we (OSCOAP) agree with ha= ving this in an appendix if your prefer. Wondering why mandating alg in ext= ernal_aad wouldn=E2=80=99t be =E2=80=9Cexplicit enough=E2=80=9D.

=

=C2=A0

Francesca<= /p>


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


--001a113b9ce4ca71f1052b0cb303-- From nobody Sat Feb 6 15:00:41 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 E8FF71A1A42 for ; Sat, 6 Feb 2016 15:00:40 -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 mhq-kTDoevDw for ; Sat, 6 Feb 2016 15:00:39 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext7.iad.github.net [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956C91A1A27 for ; Sat, 6 Feb 2016 15:00:39 -0800 (PST) Date: Sat, 06 Feb 2016 15:00:36 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1454799636; bh=RQPQoOycT7H4HnppHGSj/kghJeLFs/CtaS5SLCJAwqk=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=tidzqiL6GJfAqkODl7KfPSRmI1GIKL2IwwUIxqMVAryns7NnMrHzPZqkEBHY2g/9S 76CXC6Yz54u5L5uBX7kCdNWB9xtm3WX+tagICkcBPJ0+UWJUbmL5hDU8pPqwH8Odn9 xRWhI+T4GTTbTeIPYize5Bd0GMZAy3kodmclrgyg= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56b67b148ba61_37f63fa7658012bc99294"; 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] Define a curve registry. (#55) 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: Sat, 06 Feb 2016 23:00:41 -0000 ----==_mimepart_56b67b148ba61_37f63fa7658012bc99294 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #55. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/55#event-541918029 ----==_mimepart_56b67b148ba61_37f63fa7658012bc99294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #55.

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

----==_mimepart_56b67b148ba61_37f63fa7658012bc99294-- From nobody Sat Feb 6 18:31:01 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 F21631AD49D for ; Sat, 6 Feb 2016 18:30:59 -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 LP-DfTx4rCIQ for ; Sat, 6 Feb 2016 18:30:58 -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 566D01AD374 for ; Sat, 6 Feb 2016 18:30:58 -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 3EE9838F0C; Sat, 6 Feb 2016 18:30:57 -0800 (PST) From: "Jim Schaad" To: References: <029401d15f13$3399f480$9acddd80$@augustcellars.com> <20160204120602.GA17773@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160204120602.GA17773@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sat, 6 Feb 2016 18:28:24 -0800 Message-ID: <04ec01d1614f$38cdff30$aa69fd90$@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: AQLibC2PuH4t2IgD+NFTRLhOYTNk4gHAYiMfnO+/FBA= Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] Issue #51 - make "alg" field optional 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, 07 Feb 2016 02:31:00 -0000 > -----Original Message----- > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > Sent: Thursday, February 04, 2016 4:06 AM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [COSE] Issue #51 - make "alg" field optional >=20 > On Wed, Feb 03, 2016 at 10:13:44PM -0800, Jim Schaad wrote: > > I have been trying to figure out a way forward on this issue that = will > > make all parties happy and I have not been successful. I am = therefore > > going to open this up for discussion to see if it is possible as a > > group to come up with a solution that will appeal to everybody. I > > doubt that it is going to be doable. > > > > The request in the issue is to relax the current restriction where = the > > alg MUST be present in each message oriented object defined by COSE. > > There is current a requirement that the item be present and that, if > > possible, it MUST be in the protected bucket of header items. >=20 > Thinking what I would think is proper, I would associate the algorithm = with the > key. Either external key, or contained in protected members of = enveloped key. For external keys, the current document follows the lead of JOSE and = doesn=E2=80=99t require an algorithm identifier to be passed with keys. = This would be necessary for COSE in order to make an association of an = algorithm and a key to exist. I would also expect that there would need = to be some language about binding one and only one algorithm to a key. We do not have an ability to do something different than what we = currently do for cases where a key is distributed in a message. = However, it is probably considered to be acceptable. >=20 > Even putting the algorithm in protected members of the object itself = would not > protect against all substitution attacks (I think Ed25519 vs. > Ed25519ph substitution for instance). I don't agree with this statement. If the algorithm identifier is part = of the string that is being signed and the application uses that = identifier to determine what algorithm is being used to evaluate the = validity of the signature, an attacker that changes the algorithm in the = signed string would result in an invalid signature being received by the = evaluation system. This is, IMHO, the crux of preventing an algorithm = substitution attack. The ability to determine that the algorithm I use = and the algorithm you use are the same. (If you lie about it and sign = the wrong algorithm identifier then that would be an undetectable = error.) In terms of Ed25519 and #d25519pH, I consider the fact that these are = two different algorithms to be a distinction without a difference. One = can use the same software code to process these two different signatures = and one will both produce and validate the same set of signatures. It = is really hard for me to therefore say that the signature algorithms are = distinct. What is distinct is how they are thought about for doing = security proofs and how they would be implemented in an API sense. =20 >=20 > In any case, repeating already implicitly known algorithm is good = source of > security bugs... I don't think that I would agree with this statement. Making explicit = what is implicit should not be an error unless you believe that people = will like about what the algorithm is and refuse to fail if the explicit = and implicit algorithm are different. Jim >=20 > I haven't thought how much trouble that kind of architecture would = cause in > COSE... >=20 >=20 > -Ilari From nobody Sat Feb 6 18:33:51 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 D6D031B29BF for ; Sat, 6 Feb 2016 18:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 CL1Sbft1p3Hc for ; Sat, 6 Feb 2016 18:33:47 -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 5FB3A1B29A3 for ; Sat, 6 Feb 2016 18:33:47 -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 B499F2C9FB; Sat, 6 Feb 2016 18:33:46 -0800 (PST) From: "Jim Schaad" To: "'Francesca Palombini'" , References: In-Reply-To: Date: Sat, 6 Feb 2016 18:31:14 -0800 Message-ID: <04ed01d1614f$9dd508b0$d97f1a10$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04EE_01D1610C.8FB264F0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQHTPrVKql3wIIrjyaPbSpFFbO+rGZ8cIVyg Archived-At: Subject: Re: [COSE] Issue #51 - make "alg" field optional 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, 07 Feb 2016 02:33:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04EE_01D1610C.8FB264F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Francesca Palombini [mailto:francesca.palombini@ericsson.com] Sent: Friday, February 05, 2016 3:04 AM To: Jim Schaad ; cose@ietf.org Subject: Re: [COSE] Issue #51 - make "alg" field optional Hi Jim and all, We are not against having this relaxation discussed in an appendix instead of in the core of the draft, as long as it is in the COSE document. We will define in (the next version of) OSCOAP exactly how the external_aad is constructed (and that it includes alg). Between your choices, we would prefer to have the discussion about optional alg in an appendix of the COSE draft (that we can refer to) rather than defining it ourselves in the OSCOAP draft. Defining the alg to be optional in OSCOAP while having it mandatory in COSE would create a discrepancy between the two documents, and I believe it would create confusion for future implementers. I understand you do not want to leave the door open for misinterpretation, and prefer to have a strong "default" behavior that cannot be misunderstood and would not create security issues derived by "common use" ; on the other hand I don't understand how could the sentence "either you include the algorithm in the (protected part of the) message or in the externally supplied aad" be misunderstood. Why wouldn't the restriction "no alg --> alg in external_aad" be enough in the COSE document, leaving the task to exactly define the external_aad to the application? I am confused here because it looks to me as if you would rather accept discrepancies between COSE and application spec rather than mandate that "the alg must be included in the external_aad". In my opinion the first would create more confusion than the second. But I'm interested in hearing the opinion of the group of course. tl;dr we (OSCOAP) agree with having this in an appendix if your prefer. Wondering why mandating alg in external_aad wouldn't be "explicit enough". [JLS] The issue for me is that even if we mandate that an application must create an external_aad structure and include it, a generic application might not do this if it was going to be slightly mis-behaved. Making the application need to do this explicitly puts the onus on the application to get it right and not be implicit from the COSE spec. Jim Francesca ------=_NextPart_000_04EE_01D1610C.8FB264F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: = Francesca Palombini [mailto:francesca.palombini@ericsson.com] =
Sent: Friday, February 05, 2016 3:04 AM
To: Jim = Schaad <ietf@augustcellars.com>; cose@ietf.org
Subject: = Re: [COSE] Issue #51 - make "alg" field = optional

 

Hi Jim and = all,

 

We are not against having this relaxation discussed in = an appendix instead of in the core of the draft, as long as it is in the = COSE document. We will define in (the next version of) OSCOAP exactly = how the external_aad is constructed (and that it includes alg). =

 

Between your choices, we would prefer to have the = discussion about optional alg in an appendix of the COSE draft (that we = can refer to) rather than defining it ourselves in the OSCOAP draft. = Defining the alg to be optional in OSCOAP while having it mandatory in = COSE would create a discrepancy between the two documents, and I believe = it would create confusion for future implementers.

 

I understand = you do not want to leave the door open for misinterpretation, and prefer = to have a strong “default” behavior that cannot be = misunderstood and would not create security issues derived by = “common use” ; on the other hand I don’t understand = how could the sentence “either you include the algorithm in the = (protected part of the) message or in the externally supplied aad” = be misunderstood. Why wouldn’t the restriction “no alg = --> alg in external_aad” be enough in the COSE document, = leaving the task to exactly define the external_aad to the = application?

 

I am confused here because it looks to me as if you = would rather accept discrepancies between COSE and application spec = rather than mandate that “the alg must be included in the = external_aad”. In my opinion the first would create more confusion = than the second.  But I’m interested in hearing the opinion = of the group of course.

 

tl;dr we = (OSCOAP) agree with having this in an appendix if your prefer. Wondering = why mandating alg in external_aad wouldn’t be “explicit = enough”.

 

[JLS] The issue for me = is that even if we mandate that an application must create an = external_aad structure and include it, a generic application might not = do this if it was going to be slightly mis-behaved.  Making the = application need to do this explicitly puts the onus on the application = to get it right and not be implicit from the COSE = spec.

 

Jim

 

 

Francesca

------=_NextPart_000_04EE_01D1610C.8FB264F0-- From nobody Sat Feb 6 18:35:51 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 A57CC1B2ACD for ; Sat, 6 Feb 2016 18:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 alJuYMXn-FVj for ; Sat, 6 Feb 2016 18:35:47 -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 719441B2AB6 for ; Sat, 6 Feb 2016 18:35:47 -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 C84F82C9EF; Sat, 6 Feb 2016 18:35:46 -0800 (PST) From: "Jim Schaad" To: "'Samuel Erdtman'" , "'Francesca Palombini'" References: In-Reply-To: Date: Sat, 6 Feb 2016 18:33:12 -0800 Message-ID: <04f201d1614f$e56e0b40$b04a21c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04F3_01D1610C.D74D8A60" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQHTPrVKql3wIIrjyaPbSpFFbO+rGQMqRMUZnwLPvsA= Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] Issue #51 - make "alg" field optional 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, 07 Feb 2016 02:35:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04F3_01D1610C.D74D8A60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Samuel Erdtman [mailto:samuel@erdtman.se]=20 Sent: Friday, February 05, 2016 1:41 PM To: Francesca Palombini Cc: Jim Schaad ; cose@ietf.org Subject: Re: [COSE] Issue #51 - make "alg" field optional =20 Hi Francesca and all, =20 I might have missed some previous discussion but I don=C2=B4t get why it = is better to have the alg parameter in external_aad than as part of the = COSE message. When I read your reply I interpret it as, alg is = mandatory, but you are allowed to put it in the COSE message or in the = external_aad. What benefit am I missing? =20 [JLS] External_aad is constructed locally by the clients and is not = transmitted as part of the COSE message. This means that the datagram = that includes the COSE message object would be smaller by a couple of = bytes (normally 2, one for the header identifier and one for the = algorithm identifier). =20 =20 jim =20 Regards //Samuel =20 =20 =20 On Fri, Feb 5, 2016 at 12:03 PM, Francesca Palombini = > wrote: Hi Jim and all, =20 We are not against having this relaxation discussed in an appendix = instead of in the core of the draft, as long as it is in the COSE = document. We will define in (the next version of) OSCOAP exactly how the = external_aad is constructed (and that it includes alg).=20 =20 Between your choices, we would prefer to have the discussion about = optional alg in an appendix of the COSE draft (that we can refer to) = rather than defining it ourselves in the OSCOAP draft. Defining the alg = to be optional in OSCOAP while having it mandatory in COSE would create = a discrepancy between the two documents, and I believe it would create = confusion for future implementers. =20 I understand you do not want to leave the door open for = misinterpretation, and prefer to have a strong =E2=80=9Cdefault=E2=80=9D = behavior that cannot be misunderstood and would not create security = issues derived by =E2=80=9Ccommon use=E2=80=9D ; on the other hand I = don=E2=80=99t understand how could the sentence =E2=80=9Ceither you = include the algorithm in the (protected part of the) message or in the = externally supplied aad=E2=80=9D be misunderstood. Why wouldn=E2=80=99t = the restriction =E2=80=9Cno alg --> alg in external_aad=E2=80=9D be = enough in the COSE document, leaving the task to exactly define the = external_aad to the application? =20 I am confused here because it looks to me as if you would rather accept = discrepancies between COSE and application spec rather than mandate that = =E2=80=9Cthe alg must be included in the external_aad=E2=80=9D. In my = opinion the first would create more confusion than the second. But = I=E2=80=99m interested in hearing the opinion of the group of course. =20 tl;dr we (OSCOAP) agree with having this in an appendix if your prefer. = Wondering why mandating alg in external_aad wouldn=E2=80=99t be = =E2=80=9Cexplicit enough=E2=80=9D. =20 Francesca _______________________________________________ COSE mailing list COSE@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose =20 ------=_NextPart_000_04F3_01D1610C.D74D8A60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: Friday, = February 05, 2016 1:41 PM
To: Francesca Palombini = <francesca.palombini@ericsson.com>
Cc: Jim Schaad = <ietf@augustcellars.com>; cose@ietf.org
Subject: Re: = [COSE] Issue #51 - make "alg" field = optional

 

Hi = Francesca and all,

 

I = might have missed some previous discussion but I don=C2=B4t get why it = is better to have the alg parameter in external_aad = than as part of the COSE message. When I read your reply I interpret it = as, alg is mandatory, but you are allowed to put it in the COSE message = or in the external_aad. What benefit am I = missing?

 

[JLS]=C2=A0 External_aad =C2=A0is constructed locally by the clients = and is not transmitted as part of the COSE message.=C2=A0 This means = that the datagram that includes the COSE message object would be smaller = by a couple of bytes (normally 2, one for the header identifier and one = for the algorithm identifier).=C2=A0

 

jim

 

Regards

//Samuel

 

 

 

On Fri, = Feb 5, 2016 at 12:03 PM, Francesca Palombini <francesca.palombini@ericsson.com> = wrote:

Hi Jim and = all,

 

We are not = against having this relaxation discussed in an appendix instead of in = the core of the draft, as long as it is in the COSE document. We will = define in (the next version of) OSCOAP exactly how the external_aad is = constructed (and that it includes alg).

 

Between = your choices, we would prefer to have the discussion about optional alg = in an appendix of the COSE draft (that we can refer to) rather than = defining it ourselves in the OSCOAP draft. Defining the alg to be = optional in OSCOAP while having it mandatory in COSE would create a = discrepancy between the two documents, and I believe it would create = confusion for future implementers.

 

I = understand you do not want to leave the door open for misinterpretation, = and prefer to have a strong =E2=80=9Cdefault=E2=80=9D behavior that = cannot be misunderstood and would not create security issues derived by = =E2=80=9Ccommon use=E2=80=9D ; on the other hand I don=E2=80=99t = understand how could the sentence =E2=80=9Ceither you include the = algorithm in the (protected part of the) message or in the externally = supplied aad=E2=80=9D be misunderstood. Why wouldn=E2=80=99t the = restriction =E2=80=9Cno alg --> alg in external_aad=E2=80=9D be = enough in the COSE document, leaving the task to exactly define the = external_aad to the application?

 

I am = confused here because it looks to me as if you would rather accept = discrepancies between COSE and application spec rather than mandate that = =E2=80=9Cthe alg must be included in the external_aad=E2=80=9D. In my = opinion the first would create more confusion than the second.  But = I=E2=80=99m interested in hearing the opinion of the group of = course.

 

tl;dr we = (OSCOAP) agree with having this in an appendix if your prefer. Wondering = why mandating alg in external_aad wouldn=E2=80=99t be =E2=80=9Cexplicit = enough=E2=80=9D.

 

Francesca


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

 

------=_NextPart_000_04F3_01D1610C.D74D8A60-- From nobody Sat Feb 6 19:59: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 174FF1B31D6; Sat, 6 Feb 2016 19:59: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, 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 Oa2NcQ3dGjJy; Sat, 6 Feb 2016 19:59:12 -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 81F901B31BF; Sat, 6 Feb 2016 19:59:12 -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 B654C38EF8; Sat, 6 Feb 2016 19:59:11 -0800 (PST) From: "Jim Schaad" To: References: <0c9901d14736$e2353940$a69fabc0$@augustcellars.com> <568AED5E.7000408@cs.tcd.ie> In-Reply-To: <568AED5E.7000408@cs.tcd.ie> Date: Sat, 6 Feb 2016 19:56:39 -0800 Message-ID: <050301d1615b$8ca13b70$a5e3b250$@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: AQLlEEvf79rpkp+SgCb/nHXkvCWZkALyuLCEnOEAncA= Archived-At: Cc: core@ietf.org, 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: Sun, 07 Feb 2016 03:59:15 -0000 Before I close this issue, does anyone else want to weight in? Jim > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Monday, January 04, 2016 2:09 PM > To: Jim Schaad ; cose@ietf.org > Cc: Ace@ietf.org > Subject: Re: [Ace] Should we support padding for Enveloped/Encrypted > Messages > > > 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 > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Sun Feb 7 05:08:03 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 C36C91B3A31 for ; Sun, 7 Feb 2016 05:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 xdn515b0fT03 for ; Sun, 7 Feb 2016 05:07:59 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 969651B3A27 for ; Sun, 7 Feb 2016 05:07:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 0CF99683; Sun, 7 Feb 2016 15:07:57 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id LeZNJ4-XYm8J; Sun, 7 Feb 2016 15:07:56 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id D0DFCC4; Sun, 7 Feb 2016 15:07:56 +0200 (EET) Date: Sun, 7 Feb 2016 15:07:54 +0200 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20160207130754.GA415@LK-Perkele-V2.elisa-laajakaista.fi> References: <029401d15f13$3399f480$9acddd80$@augustcellars.com> <20160204120602.GA17773@LK-Perkele-V2.elisa-laajakaista.fi> <04ec01d1614f$38cdff30$aa69fd90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <04ec01d1614f$38cdff30$aa69fd90$@augustcellars.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] Issue #51 - make "alg" field optional 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, 07 Feb 2016 13:08:01 -0000 On Sat, Feb 06, 2016 at 06:28:24PM -0800, Jim Schaad wrote: > > > Even putting the algorithm in protected members of the object itself would not > > protect against all substitution attacks (I think Ed25519 vs. > > Ed25519ph substitution for instance). > > I don't agree with this statement. If the algorithm identifier is > part of the string that is being signed and the application uses that > identifier to determine what algorithm is being used to evaluate the > validity of the signature, an attacker that changes the algorithm in > the signed string would result in an invalid signature being received > by the evaluation system. Get signature that is valid for both Ed25519 and Ed25519ph, including the algorithm indications. The complexity of doing this is WAY below breaking the curve or the hash. > What is distinct is how they > are thought about for doing security proofs and how they would be > implemented in an API sense. The API for both should be the same. IMO, the sole reason Ed25519ph exists is that some want to use bad legacy APIs in "exciting" way. Actually, I should remove it from JOSE draft. My advice about it: Don't use. > > > > In any case, repeating already implicitly known algorithm is > > good source of security bugs... > > I don't think that I would agree with this statement. Making > explicit what is implicit should not be an error unless you > believe that people will like about what the algorithm is and > refuse to fail if the explicit and implicit algorithm are different. Well, repeating information in multiple places is _legendary_ source of bugs all around, and when you got a security protocol, some of those bugs become security bugs. -Ilari From nobody Sun Feb 7 16:35:55 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 BA66B1A86FC for ; Sun, 7 Feb 2016 16:35:53 -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 lmd2dV_9lD4w for ; Sun, 7 Feb 2016 16:35:52 -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 1203F1A86FE for ; Sun, 7 Feb 2016 16:35:51 -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 87A8138EF4; Sun, 7 Feb 2016 16:35:50 -0800 (PST) From: "Jim Schaad" To: References: <029401d15f13$3399f480$9acddd80$@augustcellars.com> <20160204120602.GA17773@LK-Perkele-V2.elisa-laajakaista.fi> <04ec01d1614f$38cdff30$aa69fd90$@augustcellars.com> <20160207130754.GA415@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160207130754.GA415@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sun, 7 Feb 2016 16:33:17 -0800 Message-ID: <001401d16208$4e28c450$ea7a4cf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLibC2PuH4t2IgD+NFTRLhOYTNk4gHAYiMfAfpZ4NABhGMPQ5zVCICA Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] Issue #51 - make "alg" field optional 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, 08 Feb 2016 00:35:53 -0000 > -----Original Message----- > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > Sent: Sunday, February 07, 2016 5:08 AM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [COSE] Issue #51 - make "alg" field optional >=20 > On Sat, Feb 06, 2016 at 06:28:24PM -0800, Jim Schaad wrote: > > > > > Even putting the algorithm in protected members of the object = itself > > > would not protect against all substitution attacks (I think = Ed25519 vs. > > > Ed25519ph substitution for instance). > > > > I don't agree with this statement. If the algorithm identifier is > > part of the string that is being signed and the application uses = that > > identifier to determine what algorithm is being used to evaluate the > > validity of the signature, an attacker that changes the algorithm in > > the signed string would result in an invalid signature being = received > > by the evaluation system. >=20 > Get signature that is valid for both Ed25519 and Ed25519ph, including = the > algorithm indications. The complexity of doing this is WAY below = breaking the > curve or the hash. If this is a true statement, then you should be strenuously objecting to = having the IRTF publish this pair of algorithms. This says that these = algorithms are so close to each other than having both is a severe = problem that cannot be overcome. While I understand that Ed25519(SHA512(M)) =3D=3D=3D Ed25519ph(M), = Changing a byte in M, which is what would be required to change the = algorithm indicator, is the same as needing to break the hash. Could = you layout what you think the attack is where this would not be the = case? (Does it need to be done on CFRG instead?)=20 >=20 > > What is distinct is how they > > are thought about for doing security proofs and how they would be > > implemented in an API sense. >=20 > The API for both should be the same. IMO, the sole reason Ed25519ph = exists is > that some want to use bad legacy APIs in "exciting" way. >=20 > Actually, I should remove it from JOSE draft. My advice about it: > Don't use. I would be happy with this change. >=20 > > > > > > In any case, repeating already implicitly known algorithm is good > > > source of security bugs... > > > > I don't think that I would agree with this statement. Making = explicit > > what is implicit should not be an error unless you believe that = people > > will like about what the algorithm is and refuse to fail if the > > explicit and implicit algorithm are different. >=20 > Well, repeating information in multiple places is _legendary_ source = of bugs all > around, and when you got a security protocol, some of those bugs = become > security bugs. I hear what you are saying. In this case I do not agree since I do not = believe that the implicit algorithm is going to be generically there.=20 Jim >=20 >=20 >=20 > -Ilari From nobody Sun Feb 7 20:21:47 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 29C711A9062; Sun, 7 Feb 2016 20:21:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160208042145.24820.74118.idtracker@ietfa.amsl.com> Date: Sun, 07 Feb 2016 20:21:45 -0800 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-10.txt 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: Mon, 08 Feb 2016 04:21:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption of the IETF. Title : CBOR Encoded Message Syntax Author : Jim Schaad Filename : draft-ietf-cose-msg-10.txt Pages : 105 Date : 2016-02-07 Abstract: Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have the basic security services defined for this data format. This document specifies processing for signatures, message authentication codes, and encryption using CBOR. This document also specifies a representation for cryptographic keys using CBOR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 7 20:31: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 AED451A907C for ; Sun, 7 Feb 2016 20:31:45 -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 1jnl1_hHtAs4 for ; Sun, 7 Feb 2016 20:31:44 -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 32DEA1A905E for ; Sun, 7 Feb 2016 20:31:44 -0800 (PST) Received: from hebrews (unknown [64.122.12.145]) (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 8DF0238EE7 for ; Sun, 7 Feb 2016 20:31:43 -0800 (PST) From: "Jim Schaad" To: References: <20160208042145.24820.37300.idtracker@ietfa.amsl.com> In-Reply-To: <20160208042145.24820.37300.idtracker@ietfa.amsl.com> Date: Sun, 7 Feb 2016 20:29:09 -0800 Message-ID: <001801d16229$41c9a410$c55cec30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE71YXHLsFdxJ2tXd79Peo2WUxLeKBMphxQ Content-Language: en-us Archived-At: Subject: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10.txt 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, 08 Feb 2016 04:31:45 -0000 This version should address all of the open issues in the tracker except = for the optional algorithm pair of items (#51 and #52). There are two issues that are still unmarked as resolved that are = probably not of great importance #54 is only important to the OSCoAP people if they are not planning to = use the CBOR content type option #53 went out for comment at the start of January and gathered crickets = (except for a comment of that would be nice from Stephen Ferrell). Ilari - Once upon a time you made a comment about the context structure = and the header fields that can optionally be used for population of it. = I have since done a couple of passes trying to do a re-write on it to = make things clearer. Can you please check if your issue (current CREF2) = has been resolve? Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, February 07, 2016 8:22 PM > To: Jim Schaad > Subject: New Version Notification for draft-ietf-cose-msg-10.txt >=20 >=20 > A new version of I-D, draft-ietf-cose-msg-10.txt has been successfully = submitted > by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-ietf-cose-msg > Revision: 10 > Title: CBOR Encoded Message Syntax > Document date: 2016-02-07 > Group: cose > Pages: 105 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-10.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-10 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-msg-10 >=20 > Abstract: > Concise Binary Object Representation (CBOR) is data format designed > for small code size and small message size. There is a need for = the > ability to have the basic security services defined for this data > format. This document specifies processing for signatures, message > authentication codes, and encryption using CBOR. This document = also > specifies a representation for cryptographic keys using CBOR. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Sun Feb 7 23:11: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 A37931AC427 for ; Sun, 7 Feb 2016 23:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 YWMko1BEXfwO for ; Sun, 7 Feb 2016 23:11:41 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD511AC424 for ; Sun, 7 Feb 2016 23:11:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 96CF1675; Mon, 8 Feb 2016 09:11:40 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id fiV-K4r_JWeW; Mon, 8 Feb 2016 09:11:40 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 68D22230D; Mon, 8 Feb 2016 09:11:40 +0200 (EET) Date: Mon, 8 Feb 2016 09:11:38 +0200 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20160208071138.GB12661@LK-Perkele-V2.elisa-laajakaista.fi> References: <029401d15f13$3399f480$9acddd80$@augustcellars.com> <20160204120602.GA17773@LK-Perkele-V2.elisa-laajakaista.fi> <04ec01d1614f$38cdff30$aa69fd90$@augustcellars.com> <20160207130754.GA415@LK-Perkele-V2.elisa-laajakaista.fi> <001401d16208$4e28c450$ea7a4cf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <001401d16208$4e28c450$ea7a4cf0$@augustcellars.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] Issue #51 - make "alg" field optional 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, 08 Feb 2016 07:11:43 -0000 On Sun, Feb 07, 2016 at 04:33:17PM -0800, Jim Schaad wrote: > > > Get signature that is valid for both Ed25519 and Ed25519ph, including the > > algorithm indications. The complexity of doing this is WAY below breaking the > > curve or the hash. > > If this is a true statement, then you should be strenuously objecting > to having the IRTF publish this pair of algorithms. This says that > these algorithms are so close to each other than having both is a > severe problem that cannot be overcome. There actually is some stuff about this in security considerations. Maybe it isn't clear enough. > While I understand that Ed25519(SHA512(M)) === Ed25519ph(M), > Changing a byte in M, which is what would be required to change > the algorithm indicator, is the same as needing to break the hash. Actually, for COSE case, it isn't even close to breaking the hash, but however due to sig_struct internal structure, it actually seems be close to breaking the curve. To see example of where things go badly wrong, consider the following signature format: 1 byte: 01=>Ed25519, 02=>Ed25519ph levarint: Length of signed data. octets: signed data Then try message "ABCDEFGHJ71610" with Ed25519 to see things going south. -Ilari From nobody Mon Feb 8 05:19:15 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 C17E61B2AA1 for ; Mon, 8 Feb 2016 05:19:14 -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 WhiQrSDTlPVA for ; Mon, 8 Feb 2016 05:19:12 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768741B2A9F for ; Mon, 8 Feb 2016 05:19:12 -0800 (PST) X-AuditID: 12074423-e13ff70000003fd1-1b-56b895cfe84c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 71.D3.16337.FC598B65; Mon, 8 Feb 2016 08:19:11 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u18DJATT025402 for ; Mon, 8 Feb 2016 08:19:11 -0500 Received: from [192.168.128.56] (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 u18DJ8EF023242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 8 Feb 2016 08:19:10 -0500 To: cose@ietf.org References: <20160208042145.24820.37300.idtracker@ietfa.amsl.com> <001801d16229$41c9a410$c55cec30$@augustcellars.com> From: Justin Richer Message-ID: <56B895CA.8060104@mit.edu> Date: Mon, 8 Feb 2016 08:19:06 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <001801d16229$41c9a410$c55cec30$@augustcellars.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixG6nrnt+6o4wg9V/JC2mbZ3K6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN1H97IV7BKr2L/yDHsD42ShLkZODgkBE4nWff3sXYxcHEIC bUwSc7dNYoRwjjBKLP99gRXCeccksXPjJ0aQFmGBQImPE3cDtXBwiAgIStztNAcxhQTKJfa0 KIFUsAmoSkxf08IEYvMKqEn8+viMFcRmEVCR2PzkIDOILSoQI3Gx8whUjaDEyZlPWEBsTgEH ic6GOewgNrOArcSdubuZIWx5ie1v5zBPYOSfhaRlFpKyWUjKFjAyr2KUTcmt0s1NzMwpTk3W LU5OzMtLLdI108vNLNFLTSndxAgOPRflHYx/DiodYhTgYFTi4VVo2x4mxJpYVlyZe4hRkoNJ SZS3sHlHmBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3h29QDnelMTKqtSifJiUNAeLkjivEf+m MCGB9MSS1OzU1ILUIpisDAeHkgSvKTDGhASLUtNTK9Iyc0oQ0kwcnCDDeYCGa4HU8BYXJOYW Z6ZD5E8x6nJM2/1gLZMQS15+XqqUOO/9KUBFAiBFGaV5cHNAKSPh7WHTV4ziQG8J894CqeIB phu4Sa+AljABLVnxbxvIkpJEhJRUA+PU5LtFa0NcrgY9vmvBMVmq2ktbeOpDzu8KutzZN/7V 7Xl0qt3e4Ug3S8amvycmtV6texe4IIMliO/EC4Og0ncHdzDsWnipvfZYqdxcrX+qMTMvZB4+ zXJ90eytRn7m3/TVFEsty8/eCJJvYVd9+Nevx9/z+ZnYa4WhprmOVnu2KZ84fObofAElluKM REMt5qLiRAAA/CA69AIAAA== Archived-At: Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10.txt 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, 08 Feb 2016 13:19:14 -0000 Hello everybody, Please review the list of completed issues in the tracker against the new version of the document: https://github.com/cose-wg/cose-issues/issues?q=is%3Aissue+is%3Aopen+label%3AComplete We will close all issues marked as "Complete" in one week if there is no contention on the issue. -- Justin, your COSE chair On 2/7/2016 11:29 PM, Jim Schaad wrote: > This version should address all of the open issues in the tracker except for the optional algorithm pair of items (#51 and #52). > There are two issues that are still unmarked as resolved that are probably not of great importance > > #54 is only important to the OSCoAP people if they are not planning to use the CBOR content type option > #53 went out for comment at the start of January and gathered crickets (except for a comment of that would be nice from Stephen Ferrell). > > Ilari - Once upon a time you made a comment about the context structure and the header fields that can optionally be used for population of it. I have since done a couple of passes trying to do a re-write on it to make things clearer. Can you please check if your issue (current CREF2) has been resolve? > > Jim > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Sunday, February 07, 2016 8:22 PM >> To: Jim Schaad >> Subject: New Version Notification for draft-ietf-cose-msg-10.txt >> >> >> A new version of I-D, draft-ietf-cose-msg-10.txt has been successfully submitted >> by Jim Schaad and posted to the IETF repository. >> >> Name: draft-ietf-cose-msg >> Revision: 10 >> Title: CBOR Encoded Message Syntax >> Document date: 2016-02-07 >> Group: cose >> Pages: 105 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-10.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-10 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-10 >> >> Abstract: >> Concise Binary Object Representation (CBOR) is data format designed >> for small code size and small message size. There is a need for the >> ability to have the basic security services defined for this data >> format. This document specifies processing for signatures, message >> authentication codes, and encryption using CBOR. This document also >> specifies a representation for cryptographic keys using CBOR. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Feb 8 07:33:07 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 903E71B2D3F for ; Mon, 8 Feb 2016 07:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 oPguxCZT-Csq for ; Mon, 8 Feb 2016 07:33:03 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 935281B2D40 for ; Mon, 8 Feb 2016 07:33:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 1999B648; Mon, 8 Feb 2016 17:33:02 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id DdJUcpkqvMWD; Mon, 8 Feb 2016 17:33:01 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id E2A3C21C; Mon, 8 Feb 2016 17:33:01 +0200 (EET) Date: Mon, 8 Feb 2016 17:32:59 +0200 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20160208153259.GC12661@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160208042145.24820.37300.idtracker@ietfa.amsl.com> <001801d16229$41c9a410$c55cec30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <001801d16229$41c9a410$c55cec30$@augustcellars.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10.txt 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, 08 Feb 2016 15:33:05 -0000 On Sun, Feb 07, 2016 at 08:29:09PM -0800, Jim Schaad wrote: > > Ilari - Once upon a time you made a comment about the context > structure and the header fields that can optionally be used for > population of it. I have since done a couple of passes trying > to do a re-write on it to make things clearer. Can you please > check if your issue (current CREF2) has been resolve? Looks decent... Maybe table 13 could be moved up just under the reference to it, so the CBOR encoding description isn't between table and reference to it? -Ilari From nobody Fri Feb 12 08:17:06 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 5AD931A21C3 for ; Fri, 12 Feb 2016 08:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Rg9opzzn217d for ; Fri, 12 Feb 2016 08:17:02 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190DC1A21C2 for ; Fri, 12 Feb 2016 08:17:01 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-12-56be057b5485 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 11.59.20792.B750EB65; Fri, 12 Feb 2016 17:17:00 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.36]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Fri, 12 Feb 2016 17:16:59 +0100 From: Francesca Palombini To: Justin Richer , "cose@ietf.org" , "Jim Schaad" Thread-Topic: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10.txt Thread-Index: AQHRYnNQQiaMhP6EzE213JVeZKzbhp8onCTA Date: Fri, 12 Feb 2016 16:16:58 +0000 Message-ID: References: <20160208042145.24820.37300.idtracker@ietfa.amsl.com> <001801d16229$41c9a410$c55cec30$@augustcellars.com> <56B895CA.8060104@mit.edu> In-Reply-To: <56B895CA.8060104@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdS7eGdV+YwaJXjBbTtk5ltVg9/Tub xYZrL1kdmD02zpnO5rFkyU8mj6YzR5kDmKO4bFJSczLLUov07RK4Mo6sX8xS8NKhYuXby0wN jNNMuhg5OSQETCSunDjKDmGLSVy4t56ti5GLQ0jgMKPE1PPToZzFjBKPD3QxgVSxCdhIXHj4 nhXEFhHIlbhxcwZYt7BAoMTbs0tZuhg5gOJBEr9PZEGUGElsmHCMEcRmEVCVeLqzHWwMr4Cv xJolq1gg5k9hlDh55gfYTE4BdYmlH1eANTACXfT91BqwBmYBcYlbT+YzQVwqILFkz3lmCFtU 4uXjf6wgeyUEFCWW98tBlOtILNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUnYVk6iwkLbOQtMxC 0rKAkWUVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmDsHNzy22oH48HnjocYBTgYlXh4DW7t CRNiTSwrrsw9xCjBwawkwmvQtDdMiDclsbIqtSg/vqg0J7X4EKM0B4uSOO8a5/VhQgLpiSWp 2ampBalFMFkmDk6pBsYooRMSc95ZHvF4bpv46NzuSxv+9+7ben2KKL++1/Kyy2XfU900RcpF p9cc/7RgW+vOPb8EXHhf//OykNhqFK+xyoN998+9L3yvZi6WbKtM6ZOY8aNo2e2DpY1SOjk8 aWzrrA/+9stY+d1/zbzF80t3CerbSSSwP9RxWb+KmetsoKbX31gnXjclluKMREMt5qLiRAD2 CHaAmQIAAA== Archived-At: Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10.txt 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, 12 Feb 2016 16:17:05 -0000 Hi Jim and all, I have quickly reviewed the last version of the draft and I have a couple o= f remarks. Most of them are editorial and typos I noticed, but I also have some more i= mportant questions. Starting with the Important Stuff: In our Object Security implementation, we use an identifier that identifies= a set of parameters related to protection of the message, as for example a= lgorithm, replay protection parameters, keys (possibly more than one) and o= thers. We call this "Context Identifier". This parameter is sent in the mes= sage. Following many discussion (live and by mail), we agreed on using the COSE "= kid" parameter to contain this identifier, and we haven't gotten any object= ion for it. Now, while reviewing the last version of the draft, I noticed in the kid de= finition (Section 3.1): "The value of this parameter is matched against the 'kid' member in a COSE_= Key structure." This is clearly non-compliant with our use of the "kid" header field. I see= three solutions to solve this: - Have a new parameter that complies with our context identifier (more gene= ral identifier for security related set of parameters) - "Soften" the definition of "kid": in practical terms, modify this sentenc= e so to have what was the previous version: "The value of this parameter _can be_ matched against the 'kid' member in a= COSE_Key structure." - Add an appendix about the use of the "kid", explaining that it can be use= d in other ways (although this is not the "default" use). Second question: I didn't see any decision about alg. Is there finally goin= g to be an appendix considering the case where alg is omitted from the COSE= message and following considerations about it? The editorials comments: Section 2:=20 point 4: consider replacing "in a CoAP message" with "in a CoAP payload" if= you mean Content-Format by content type parameter. Section 3:=20 "[...] most of the algorithms that are used for recipients do not provide f= or authenticated data and thus the bucket should not be used." Missing word= (s)? Section 3.1: "This parameter one of the ways that can be used to find the key to be used= ." Missing word(s)? Section 4.1: "[...] and a counter- signature." Shouldn't it be "and the counter- signatu= re" (if it is an example of parameter about the signature)? Otherwise it is= unclear. Section 4.3: "so that if they cannot be modified in transit it can be detected." Replace= "cannot be" with "are". signing and verification =3D very clear Section 4.4: point 4. of signing: consider adding the sentence: "(See Section 4.3 fo= r application guidance on constructing this field.)" as it is done in secti= on 5.2 point 4. point 4. of verifying: about the text "Place the resulting signature va= lue in the 'signature' field of the map.", this is correct for COSE_Signatu= re, but COSE_Sign1 is not a map. Section 4.5: "This means that the Sig_structure can be used for in a uniform manner to g= et the byte stream for processing a signature." Delete first "for"? Section 5.2:=20 "Examples of encrypted messages can be found in Appendix C.3." Should be C.= 4 Section 5.3 Is it possible to get section 5.3 similar in structure to 4.4 and 6.3? I wo= uld like the numbered list to be the order of the fields in the array (take= out the text in point 1.) Point 5. "Encode the Enc_structure using a CBOR Canonical encoding Sect= ion 14 to get the AAD value." Reference in parenthesis? There is no "decryption/verification" section following encryption. Can you= add some specification about that? (Analogous to the verification part of = Section 4.4) Section 6.3: Same here, there is no verification section for MAC either. Can you add som= e specification about that? Section 15:=20 "Applications need to determine the set of messages defined in this documen= t that it will be using." replace "it" with "they" (or "An application need= s ..." "When applications use externally defined authenticated data, they need to = define how that data is to be defined." Consider replace "is to be defined"= with "is to be constructed" (sounds better to me) Section 17: "While some considerations have been highlighted here, additional considera= tions may be found in the documents referred to that have full details of t= he algorithm." Not very clear to me, maybe add a comma after "referred to"?= Or consider rephrasing. "Using a the same key for two different algorithms can leak" Remove "a". "A number of factors are assoicated with this trust decision." I think you = meant "associated" "What are the permissions assoicated with the key owner?" Same here. "been checked are are correct?" Probably "and are correct" General: Consider adding references to examples in Appendix C.2 and C.6 (There is no= reference to these examples in the text). Otherwise, closed issues are OK. Best regards, Francesca -----Original Message----- From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin Richer Sent: den 8 februari 2016 14:19 To: cose@ietf.org Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10= .txt Hello everybody, Please review the list of completed issues in the tracker against the new v= ersion of the document: https://github.com/cose-wg/cose-issues/issues?q=3Dis%3Aissue+is%3Aopen+labe= l%3AComplete We will close all issues marked as "Complete" in one week if there is no co= ntention on the issue. -- Justin, your COSE chair On 2/7/2016 11:29 PM, Jim Schaad wrote: > This version should address all of the open issues in the tracker except = for the optional algorithm pair of items (#51 and #52). > There are two issues that are still unmarked as resolved that are=20 > probably not of great importance > > #54 is only important to the OSCoAP people if they are not planning to=20 > use the CBOR content type option > #53 went out for comment at the start of January and gathered crickets (e= xcept for a comment of that would be nice from Stephen Ferrell). > > Ilari - Once upon a time you made a comment about the context structure a= nd the header fields that can optionally be used for population of it. I h= ave since done a couple of passes trying to do a re-write on it to make thi= ngs clearer. Can you please check if your issue (current CREF2) has been r= esolve? > > Jim > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Sunday, February 07, 2016 8:22 PM >> To: Jim Schaad >> Subject: New Version Notification for draft-ietf-cose-msg-10.txt >> >> >> A new version of I-D, draft-ietf-cose-msg-10.txt has been=20 >> successfully submitted by Jim Schaad and posted to the IETF repository. >> >> Name: draft-ietf-cose-msg >> Revision: 10 >> Title: CBOR Encoded Message Syntax >> Document date: 2016-02-07 >> Group: cose >> Pages: 105 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-cose-msg= -10.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-10 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-msg-= 10 >> >> Abstract: >> Concise Binary Object Representation (CBOR) is data format designed >> for small code size and small message size. There is a need for the >> ability to have the basic security services defined for this data >> format. This document specifies processing for signatures, message >> authentication codes, and encryption using CBOR. This document also >> specifies a representation for cryptographic keys using CBOR. >> >> >> >> >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at tools.ie= tf.org. >> >> The IETF Secretariat > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Fri Feb 12 11:34:57 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 6B8C11A891F for ; Fri, 12 Feb 2016 11:34:55 -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 t3S9z-tofVEq for ; Fri, 12 Feb 2016 11:34:52 -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 D596D1A891C for ; Fri, 12 Feb 2016 11:34:52 -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 C289E2CA3B; Fri, 12 Feb 2016 11:34:51 -0800 (PST) From: "Jim Schaad" To: "'Francesca Palombini'" , "'Justin Richer'" , References: <20160208042145.24820.37300.idtracker@ietfa.amsl.com> <001801d16229$41c9a410$c55cec30$@augustcellars.com> <56B895CA.8060104@mit.edu> In-Reply-To: Date: Fri, 12 Feb 2016 11:32:19 -0800 Message-ID: <007001d165cc$16d078f0$44716ad0$@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: AQE71YXHLsFdxJ2tXd79Peo2WUxLeAJ5LnsHAlTpIb0CFmPdmKAcyNpw Archived-At: Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10.txt 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, 12 Feb 2016 19:34:55 -0000 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Francesca Palombini > Sent: Friday, February 12, 2016 8:17 AM > To: Justin Richer ; cose@ietf.org; Jim Schaad > > Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10.txt > > Hi Jim and all, > > I have quickly reviewed the last version of the draft and I have a couple of > remarks. > Most of them are editorial and typos I noticed, but I also have some more > important questions. > > Starting with the Important Stuff: > > In our Object Security implementation, we use an identifier that identifies a set > of parameters related to protection of the message, as for example algorithm, > replay protection parameters, keys (possibly more than one) and others. We call > this "Context Identifier". This parameter is sent in the message. > Following many discussion (live and by mail), we agreed on using the COSE "kid" > parameter to contain this identifier, and we haven't gotten any objection for it. > Now, while reviewing the last version of the draft, I noticed in the kid definition > (Section 3.1): > > "The value of this parameter is matched against the 'kid' member in a COSE_Key > structure." > > This is clearly non-compliant with our use of the "kid" header field. I see three > solutions to solve this: > - Have a new parameter that complies with our context identifier (more > general identifier for security related set of parameters) > - "Soften" the definition of "kid": in practical terms, modify this sentence > so to have what was the previous version: > > "The value of this parameter _can be_ matched against the 'kid' member in a > COSE_Key structure." I don't see this as a problem. We can easily relax the > > - Add an appendix about the use of the "kid", explaining that it can be > used in other ways (although this is not the "default" use). > > Second question: I didn't see any decision about alg. Is there finally going to be > an appendix considering the case where alg is omitted from the COSE message > and following considerations about it? As noted in the last mail I sent out, I am working on this as we speak. > > The editorials comments: > > Section 2: > point 4: consider replacing "in a CoAP message" with "in a CoAP payload" if you > mean Content-Format by content type parameter. > > Section 3: > "[...] most of the algorithms that are used for recipients do not provide for > authenticated data and thus the bucket should not be used." Missing word(s)? > > Section 3.1: > "This parameter one of the ways that can be used to find the key to be used." > Missing word(s)? > > Section 4.1: > "[...] and a counter- signature." Shouldn't it be "and the counter- signature" (if it > is an example of parameter about the signature)? Otherwise it is unclear. > > Section 4.3: > "so that if they cannot be modified in transit it can be detected." Replace > "cannot be" with "are". > > signing and verification = very clear > Section 4.4: > point 4. of signing: consider adding the sentence: "(See Section 4.3 for > application guidance on constructing this field.)" as it is done in section 5.2 point > 4. > point 4. of verifying: about the text "Place the resulting signature value in the > 'signature' field of the map.", this is correct for COSE_Signature, but COSE_Sign1 > is not a map. > > Section 4.5: > "This means that the Sig_structure can be used for in a uniform manner to get > the byte stream for processing a signature." Delete first "for"? > > Section 5.2: > "Examples of encrypted messages can be found in Appendix C.3." Should be C.4 > > Section 5.3 > Is it possible to get section 5.3 similar in structure to 4.4 and 6.3? I would like the > numbered list to be the order of the fields in the array (take out the text in point > 1.) > Point 5. "Encode the Enc_structure using a CBOR Canonical encoding Section > 14 to get the AAD value." Reference in parenthesis? > There is no "decryption/verification" section following encryption. Can you add > some specification about that? (Analogous to the verification part of Section > 4.4) > > Section 6.3: > Same here, there is no verification section for MAC either. Can you add some > specification about that? > > Section 15: > "Applications need to determine the set of messages defined in this document > that it will be using." replace "it" with "they" (or "An application needs ..." > "When applications use externally defined authenticated data, they need to > define how that data is to be defined." Consider replace "is to be defined" with > "is to be constructed" (sounds better to me) > > Section 17: > "While some considerations have been highlighted here, additional > considerations may be found in the documents referred to that have full details > of the algorithm." Not very clear to me, maybe add a comma after "referred > to"? Or consider rephrasing. > "Using a the same key for two different algorithms can leak" Remove "a". > "A number of factors are assoicated with this trust decision." I think you meant > "associated" > "What are the permissions assoicated with the key owner?" Same here. > "been checked are are correct?" Probably "and are correct" > > General: > Consider adding references to examples in Appendix C.2 and C.6 (There is no > reference to these examples in the text). > > Otherwise, closed issues are OK. I will go through the rest of these over the weekend. Jim > > Best regards, > Francesca > > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin Richer > Sent: den 8 februari 2016 14:19 > To: cose@ietf.org > Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10.txt > > Hello everybody, > > Please review the list of completed issues in the tracker against the new version > of the document: > > https://github.com/cose-wg/cose- > issues/issues?q=is%3Aissue+is%3Aopen+label%3AComplete > > We will close all issues marked as "Complete" in one week if there is no > contention on the issue. > > -- Justin, your COSE chair > > On 2/7/2016 11:29 PM, Jim Schaad wrote: > > This version should address all of the open issues in the tracker except for the > optional algorithm pair of items (#51 and #52). > > There are two issues that are still unmarked as resolved that are > > probably not of great importance > > > > #54 is only important to the OSCoAP people if they are not planning to > > use the CBOR content type option > > #53 went out for comment at the start of January and gathered crickets > (except for a comment of that would be nice from Stephen Ferrell). > > > > Ilari - Once upon a time you made a comment about the context structure and > the header fields that can optionally be used for population of it. I have since > done a couple of passes trying to do a re-write on it to make things clearer. Can > you please check if your issue (current CREF2) has been resolve? > > > > Jim > > > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Sunday, February 07, 2016 8:22 PM > >> To: Jim Schaad > >> Subject: New Version Notification for draft-ietf-cose-msg-10.txt > >> > >> > >> A new version of I-D, draft-ietf-cose-msg-10.txt has been > >> successfully submitted by Jim Schaad and posted to the IETF repository. > >> > >> Name: draft-ietf-cose-msg > >> Revision: 10 > >> Title: CBOR Encoded Message Syntax > >> Document date: 2016-02-07 > >> Group: cose > >> Pages: 105 > >> URL: https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-10.txt > >> Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > >> Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-10 > >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-10 > >> > >> Abstract: > >> Concise Binary Object Representation (CBOR) is data format designed > >> for small code size and small message size. There is a need for the > >> ability to have the basic security services defined for this data > >> format. This document specifies processing for signatures, message > >> authentication codes, and encryption using CBOR. This document also > >> specifies a representation for cryptographic keys using CBOR. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at tools.ietf.org. > >> > >> The IETF Secretariat > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Feb 15 10:08: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 A898F1ABD3C for ; Mon, 15 Feb 2016 10:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.198 X-Spam-Level: X-Spam-Status: No, score=0.198 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 pJMgbdpLgZYR for ; Mon, 15 Feb 2016 10:08:25 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985EA1ABC0F for ; Mon, 15 Feb 2016 10:08:25 -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=1hAiUS6OmJ+q8xXStD+u9ORZqXL3zyxcgcOqdPBXbAo=; b=YMcAdrOTpU0K7w8BkGRgovU/uH9Sncs1bJCKRz8u3ltPpMaP81OFHPooo91EfCkSAFC+pILkaaHBLnSoXfq6OGViuJaUorOrzjKvDq1Aqb8v+7y1ECORm7MutgzVxdngzGoRweXxtCvNS5VeXixkgCaLWKQWJc+ZWcKSft2D0to= 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.409.15; Mon, 15 Feb 2016 18:08: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.0409.017; Mon, 15 Feb 2016 18:08:24 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: =?utf-8?B?W2Nvc2UtaXNzdWVzXSBNb3ZlIOKAnGNyZWF0aW9uIHRpbWXigJ0gdmFsdWUg?= =?utf-8?Q?to_the_payload_(#13)?= Thread-Index: AQHnVbEEf4RRBeXSolS/kzUPbuZGtgLLHPuunq/hEOCABHaKgIAAPnyAgAA7WbCAAPv7AIA1ZNWQ Date: Mon, 15 Feb 2016 18:08:23 +0000 Message-ID: References: <00b401d14a72$eccb5210$c661f630$@augustcellars.com> <040d01d14ccd$30bb4140$9231c3c0$@augustcellars.com> <052701d14d68$dc395f20$94ac1d60$@augustcellars.com> In-Reply-To: <052701d14d68$dc395f20$94ac1d60$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 297a39bf-0b96-401c-3592-08d33632fed0 x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:l1NADlh6jTs2mrlyV8yo0aOvvMsIadFyNHfxvYSbTWl0/3ck5nvmpE8I+260soHmR94ZcS/qi8SxTomeUkKwQiB22HIo/yKdf5sQ++y0+PJgVi6oARxLCf2iPemc/9iGbyP1SaI0bEoT9mES31AyXA==; 24:+l/CHj2ZWbAtiVL0cQ4BXXa4Usv1u91ORxRDSC7wtQnk0VnQysSRtSmnvOvKRaiflDDEY1BpgWvGR1IfOoSS12e0iKkV7Pe1H7jzgRmmso4= 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:(102415293)(102615271)(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 08534B37A7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(19580405001)(19580395003)(1220700001)(1096002)(2900100001)(15975445007)(77096005)(87936001)(586003)(19627595001)(110136002)(189998001)(19617315012)(86362001)(3846002)(6116002)(790700001)(19609705001)(102836003)(5001960100002)(92566002)(86612001)(66066001)(4326007)(54356999)(50986999)(99936001)(18206015028)(93886004)(99286002)(5003600100002)(16236675004)(19625215002)(11100500001)(17760045003)(5004730100002)(40100003)(76176999)(74316001)(122556002)(8990500004)(76576001)(10290500002)(5002640100001)(10400500002)(5005710100001)(106116001)(33656002)(10090500001)(2906002)(5008740100001)(19300405004)(7099028); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_BY2PR03MB442117DB523E5446DB50450F5AC0BY2PR03MB442namprd_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2016 18:08:23.8194 (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: Mon, 15 Feb 2016 18:08:33 -0000 --_004_BY2PR03MB442117DB523E5446DB50450F5AC0BY2PR03MB442namprd_ Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442117DB523E5446DB50450F5AC0BY2PR03MB442namprd_" --_000_BY2PR03MB442117DB523E5446DB50450F5AC0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBJ4oCZbGwgZ3JhbnQgeW91IHRoYXQgdGhlIGNvbnRlbnQgdHlwZSB2YWx1ZSBiZWxvbmdz IGJlY2F1c2UgaXTigJlzIGdlbmVyYWxseSB1c2VmdWwgYW5kIG1ldGFkYXRhICphYm91dCogdGhl IHBheWxvYWQuICBXaGVyZWFzLCB0aGUgY3JlYXRpb24gdGltZSBmaWVsZCBpcyAqcGFydCogb2Yg dGhlIHBheWxvYWQuICBJdCBhbHNvIGR1cGxpY2F0ZXMgdGhlIENXVCBpc3N1ZWQtYXQgZmllbGQu ICBJdCBzdGlsbCBuZWVkcyB0byBiZSByZW1vdmVkIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZS4gIE1h cmtpbmcgdGhpcyBvbmUgYXMg4oCcY29tcGxldGXigJ0gaXMgYW4gaW5jb3JyZWN0IGNhdGVnb3Jp emF0aW9uIG9mIHRoZSBpc3N1ZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSmltIFNjaGFhZCBbbWFp bHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb21dDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDEyLCAy MDE2IDEwOjQyIEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t Pg0KQ2M6IGNvc2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbY29zZS1pc3N1ZXNdIE1vdmUg4oCc Y3JlYXRpb24gdGltZeKAnSB2YWx1ZSB0byB0aGUgcGF5bG9hZCAoIzEzKQ0KDQpJIGNhbm5vdCBh Z3JlZSB3aXRoIHlvdXIg4oCdYnJpZ2h0IGxpbmUgdGVzdOKAnS4gIEkgZG8gbm90IGJlbGlldmUg dGhhdCB0aGlzIHRlc3QgbWFrZXMgYW55IHNlbnNlIGFuZCBJIGRvIG5vdCBiZWxpZXZlIHRoYXQg eW91IGhhdmUgcmVhbGx5IHRob3VnaHQgdGhlIGltcGxpY2F0aW9ucyBvZiB0aGlzIHJ1bGUgdGhy b3VnaC4NCg0KDQoxLiAgICAgICAgSWYgdGhpcyBpcyByZWFsbHkgdGhlIHJ1bGUgdG8gYmUgYXBw bGllZCB0aGVuIGl0IG1ha2VzIHNlbnNlIHRvIHNheSB0aGF0IHRoaXMgc2hvdWxkIGJlIGFwcGxp ZWQgdG8gYWxsIG9mIHRoZSBoZWFkZXIgZmllbGRzLCBidXQgdGhhdCBpcyBub3Qgd2hhdCB5b3Ug YXJlIGRvaW5nLiAgVG8gc2F5IHRoYXQgY3J5cHRvZ3JhcGhpYyBydWxlcyBhcmUgcmVxdWlyZWQg d291bGQgaW1wbHkgdGhhdCB5b3Ugc2hvdWxkIGJlIGFyZ3VpbmcgdGhhdCB0aGUg4oCcY29udGVu dCB0eXBl4oCdIGhlYWRlciBmaWVsZCBzaG91bGQgYWxzbyBiZSBlbGltaW5hdGVkLiAgVGhlcmUg YXJlIG5vIGNyeXB0b2dyYXBoaWMgcnVsZXMgdGhhdCBhcmUgYXBwbGllZCB0byB0aGlzIGZpZWxk IGVpdGhlci4gIFlvdSBoYXZlIG5vdCBiZWVuIGFyZ3VpbmcgZm9yIHRoaXMgZmllbGQgdG8gYmUg cmVtb3ZlZC4NCg0KMi4gICAgICAgVGhlIGNvbmNlcHQgdGhhdCBhbiBhcHBsaWNhdGlvbiBjb3Vs ZCBkZWZpbmUgYSBoZWFkZXIgcGFyYW1ldGVyIGJ1dCB0aGlzIGRvY3VtZW50IGNhbm5vdCBkZWZp bmUgdGhlIHNwZWMgbWVhbnMgdGhhdCB0aGlzIGlzIG5vdCBhIHJ1bGUgZm9yIHRoZSByZWdpc3Ry eSwgYnV0IGEgcnVsZSBmb3IgdGhlIHNwZWNpZmljYXRpb24uICBIb3dldmVyLCB0aGUgaXQgbWFr ZXMgY29tcGxldGUgc2Vuc2UgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbiB0byBkZWZpbmUgdGhvc2Ug aGVhZGVyIGZpZWxkcyB0aGF0IGEgc2lnbmlmaWNhbnQgcG9ydGlvbiBvZiB0aGUgY29tbXVuaXR5 IGJlbGlldmVzIHRoYXQgbWlnaHQgYmUgdXNlZnVsIGZvciBhcHBsaWNhdGlvbnMgc28gdGhhdCB0 aGV5IGFyZSBpbiBhIHNpbmdsZSBzcGVjaWZpY2F0aW9uIGFuZCBsaWtlbHkgdG8gYmUgcHJvdmlk ZWQgYnkgZ2VuZXJhbCBsaWJyYXJpZXMgcmF0aGVyIHRoYW4gYmVpbmcgaW4gYSBzZWNvbmRhcnkg c3BlY2lmaWNhdGlvbiB0aGF0IGV2ZXJ5Ym9keSB3aWxsIG5lZWQgdG8gZmluZCBhbmQgc2VlIGlm IGl0IGlzIGltcGxlbWVudGVkLg0KDQozLiAgICAgICBBcyB0aGUgc3BlY2lmaWNhdGlvbiBvdXRs aW5lcywgdGhlcmUgYXJlIGNhc2VzIGluIHRoaXMgZG9jdW1lbnQgd2hlcmUgdGhpcyBmaWVsZCBj YW4gYmUgdXNlZC4gIFRvIHdpdCBjb3VudGVyIHNpZ25hdHVyZXMuICBUaGVyZSBhcmUgYSBudW1i ZXIgb2Ygb3RoZXIgY2FzZXMgd2hlcmUgdGhpcyBhbHNvIG1ha2VzIHNlbnNlIHRoYXQgYXJlIG5v dCBjb3ZlcmVkIGluIHRoaXMgZG9jdW1lbnQgYmVjYXVzZSB0aGVyZSBkb2VzIG5vdCBzZWVtIHRv IGJlIGFueSByZWFzb24gdG8gY292ZXIgdGhlbSBhcyB0aGV5IGFyZSBkZXBsb3ltZW50IHNwZWNp ZmljLiAgQnV0IHRoaXMgY291bGQgaW5jbHVkZSBnYXRld2F5IGFuZCBwcm94eSBzaWduaW5nLiAg TGlzdCBzZXJ2ZXIgc2lnbmluZyAoQ29BUCBoYXMgdGhpcyBjb25jZXB0IGJ1dCBjYWxscyBpdCBz b21ldGhpbmcgZGlmZmVyZW50LikgQWRkaXRpb25hbGx5LCB0aGUgdGltZSB0aGF0IGEgc3RhdGVt ZW50IGlzIGFzc2VydGVkIGF0IGFuZCB0aGUgdGltZSB0aGF0IHRoZSBjcnlwdG9ncmFwaGljIG9w ZXJhdGlvbiBpcyBkb25lIG1heSBiZSBkaWZmZXJlbnQgZXZlbiBmb3IgYSBDV1Qgc28gdGhhdCBp ZiB0aGlzIGZpZWxkIHdhcyB1c2VkLCBpdCBtaWdodCBub3QgYWdyZWUgd2l0aCB0aGUgY29udGVu dCBvZiB0aGUgQ1dULg0KDQo0LiAgICAgICBUaGUgY29uY2VwdCBvZiBzeW5jaHJvbml6ZWQgY2xv Y2tzIGlzIG5vdCBzb21ldGhpbmcgdGhhdCBzaG91bGQgYmUgZGlzbWlzc2VkIG91dCBvZiBoYW5k LiAgSWYgeW91IGxvb2sgYXQgdGhlIHNlbnNvciBpbiBteSBhdW504oCZcyBiYWNreWFyZCwgaXQg aXMgYSByZWxhdGl2ZWx5IGxhcmdlIHNlbnNvciBhbmQgaGFzIGEgc29sYXIgcGFuZWwgdG8gcG93 ZXIgdGhlIGJhdHRlcnkuICBUaGlzIG1lYW5zIHRoYXQgaXQgY291bGQgZWFzaWx5IGhhdmUgYSBj bG9jayBjb25maWd1cmVkIGFuZCBwb3RlbnRpYWxseSBldmVuIGJlIHN5bmNocm9uaXplZC4gIFRo ZSBzaXplIG9mIGEgc2Vuc29yIHZhcmllcyBhIGxvdCBzbyB0aGF0IHNvbWUgd2lsbCBiZSBhYmxl IHRvIGhhdmUgdGltZSBhbmQgc29tZSB3aWxsIG5vdC4NCg0KSmltDQoNCg0KRnJvbTogTWlrZSBK b25lcyBbbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbV0NClNlbnQ6IE1vbmRheSwg SmFudWFyeSAxMSwgMjAxNiA3OjQzIFBNDQpUbzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxs YXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+DQpDYzogY29zZUBpZXRmLm9y ZzxtYWlsdG86Y29zZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbY29zZS1pc3N1ZXNdIE1vdmUg 4oCcY3JlYXRpb24gdGltZeKAnSB2YWx1ZSB0byB0aGUgcGF5bG9hZCAoIzEzKQ0KDQpGYWlyIGVu b3VnaC4gIEJ1dCB0aGVyZeKAmXMgbm90aGluZyBzdG9wcGluZyB0aGUgc2Vuc29yIGFwcGxpY2F0 aW9uIGZyb20gZGVmaW5pbmcgYSBoZWFkZXIgcGFyYW1ldGVyIHRoYXQgZG9lcyBleGFjdGx5IHdo YXQgaXQgbmVlZHMgdG8gZG8sIHJlZ2lzdGVyaW5nIGl0LCBhbmQgdXNpbmcuICBUaGUg4oCcY3Jl YXRpb24gdGltZeKAnSBwYXJhbWV0ZXIgaW1wbGllcyBzeW5jaHJvbml6ZWQgY2xvY2tzLCB3aGlj aCBwcm9iYWJseSB0YWtlcyBpdCBvdXQgb2YgYXBwbGljYWJpbGl0eSBpbiB0aGUgc2Vuc29yIHNw YWNlIGFscmVhZHkuICBUaGVyZSBhcmUgbG90cyBvZiBnb29kIGFwcGxpY2F0aW9uLXNwZWNpZmlj IGNob2ljZXMuDQoNClRoZSBicmlnaHQgbGluZSB0ZXN0IGZvciBtZSB0aGF0IHNheXMgdGhhdCB0 aGlzIGhlYWRlciBwYXJhbWV0ZXIgZG9lc27igJl0IGJlbG9uZyBpbiB0aGUgY3J5cHRvIHNwZWMg aXMgdGhhdCB0aGVyZSBhcmUgbm8gY3J5cHRvZ3JhcGhpYyBwcm9jZXNzaW5nIHJ1bGVzIGZvciBp dC4gIFRoYXQgc2F5cyB0aGF0IGl04oCZcyBhcHBsaWNhdGlvbiBkYXRhIOKAkyBub3QgY3J5cHRv IGRhdGEuICBBbmQgYXMgc3VjaCwgaXQgc2hvdWxkIGJlIGRlZmluZWQgYnkgYXBwbGljYXRpb25z IOKAkyBub3QgdGhlIGNyeXB0byBzcGVjLg0KDQpQbGVhc2UgcmVtb3ZlIHRoaXMgcGFyYW1ldGVy Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBKaW0gU2NoYWFkIFttYWlsdG86aWV0ZkBhdWd1c3RjZWxs YXJzLmNvbV0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxMSwgMjAxNiA0OjA3IFBNDQpUbzogTWlr ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+Pg0KQ2M6IGNvc2VAaWV0Zi5vcmc8bWFpbHRvOmNvc2VAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSRTogW2Nvc2UtaXNzdWVzXSBNb3ZlIOKAnGNyZWF0aW9uIHRpbWXigJ0gdmFs dWUgdG8gdGhlIHBheWxvYWQgKCMxMykNCg0KSSB3aWxsIHBvaW50IG91dCB0aGF0IHRoaXMgaXMg ZGVzaWduZWQgdG8gd3JhcCB0aGluZ3Mgb3RoZXIgdGhhbiBDV1QuICBJZiB5b3UgYXJlIHdyYXBw aW5nIGEgc2Vuc29yIHJlYWRpbmcgdGhlbiB0aGVyZSBpcyBub3QgYSBDV1QgaW52b2x2ZWQgYXQg dGhhdCBwb2ludC4NCg0KSmltDQoNCg0KRnJvbTogTWlrZSBKb25lcyBbbWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbV0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxMSwgMjAxNiAxMjoy OCBQTQ0KVG86IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb208bWFpbHRvOmlldGZA YXVndXN0Y2VsbGFycy5jb20+Pg0KQ2M6IGNvc2VAaWV0Zi5vcmc8bWFpbHRvOmNvc2VAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSRTogW2Nvc2UtaXNzdWVzXSBNb3ZlIOKAnGNyZWF0aW9uIHRpbWXigJ0g dmFsdWUgdG8gdGhlIHBheWxvYWQgKCMxMykNCg0KSSBoYXZlIG5vdy4gIFRoaXMgc3RpbGwgZmVl bHMgbGlrZSB1bm5lY2Vzc2FyeSBkdXBsaWNhdGlvbiBvZiB0aGUgQ0JPUiBXZWIgVG9rZW4gKENX VCkg4oCcaWF04oCdIChpc3N1ZWQgYXQpPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC13YWhsc3Ryb2VtLWFjZS1jYm9yLXdlYi10b2tlbi0wMCNzZWN0aW9uLTMuMS42PiBjbGFpbSB0 byBtZSwgYnV0IEnigJltIGN1cmlvdXMgd2hhdCBvdGhlcnMgdGhpbmsuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN CkZyb206IEppbSBTY2hhYWQgW21haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tXQ0KU2VudDog RnJpZGF5LCBKYW51YXJ5IDgsIDIwMTYgNDoxNiBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4N CkNjOiBjb3NlQGlldGYub3JnPG1haWx0bzpjb3NlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtj b3NlLWlzc3Vlc10gTW92ZSDigJxjcmVhdGlvbiB0aW1l4oCdIHZhbHVlIHRvIHRoZSBwYXlsb2Fk ICgjMTMpDQoNCkRpZCB5b3UgcmVhZCB0aGUgY2hhbmdlIGluIHRoZSB0ZXh0IHRoYXQgd2FzIG1h ZGUgYXQgdGhlIHNhbWUgdGltZT8gICAgSXQgc3RhdGVzIHRoYXQg4oCcVGhlIGZpZWxkIGlzIHBy aW1hcmlseSBpbnRlbmRlZCB0byBiZSB0byBiZSB1c2VkIGZvciBjb3VudGVyc2lnbmF0dXJlcywg aG93ZXZlciBpdCBjYW4gYWRkaXRpb25hbGx5IGJlIHVzZWQgZm9yIHJlcGxheSBkZXRlY3Rpb24g YXMgd2VsbC7igJ0gIEl0IGlzIG5vdCBwb3NzaWJsZSB0byBwdXQgdGhlIHRpbWUgZmllbGQgaW4g dGhlIGNvbnRlbnQgZm9yIGEgY291bnRlcnNpZ25hdHVyZSBhcyB0aGVyZSBpcyBubyBjdXN0b21p emFibGUgY29udGVudCBpbiB0aGF0IGNhc2UuDQoNCg0KDQpGcm9tOiBNaWtlIEpvbmVzIFttYWls dG86bm90aWZpY2F0aW9uc0BnaXRodWIuY29tXQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMDcs IDIwMTYgNjozNCBBTQ0KVG86IGNvc2Utd2cvY29zZS1pc3N1ZXMgPGNvc2UtaXNzdWVzQG5vcmVw bHkuZ2l0aHViLmNvbTxtYWlsdG86Y29zZS1pc3N1ZXNAbm9yZXBseS5naXRodWIuY29tPj4NCkNj OiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNl bGxhcnMuY29tPj4NClN1YmplY3Q6IFJlOiBbY29zZS1pc3N1ZXNdIE1vdmUg4oCcY3JlYXRpb24g dGltZeKAnSB2YWx1ZSB0byB0aGUgcGF5bG9hZCAoIzEzKQ0KDQoNCkNoYW5naW5nIHRoZSBuYW1l IGRvZXMgbm90IGFkZHJlc3MgdGhlIGNvcmUgaXNzdWUgdGhhdCB0aGlzIGZpZWxkIGlzIHNvbGVs eSBmb3IgdXNlIGFzIGRlZmluZWQgYnkgcGFydGljdWxhciBhcHBsaWNhdGlvbnMgYW5kIGhhcyBu byBhc3NvY2lhdGVkIENPU0UgcHJvY2Vzc2luZyBydWxlcy4gVGhhdCBzYXlzIHRoYXQgaXQgYmVs b25ncyBpbiB0aGUgQ0JPUiBXZWIgVG9rZW4gZHJhZnQsIHdoaWNoIGRlZmluZXMgYXBwbGljYXRp b24gcGF5bG9hZCBmaWVsZHMsIHJhdGhlciB0aGFuIENPU0UgbWVzc2FnZXMgc3BlYy4NCg0KVGhp cyBmaWVsZCBhbHNvIGR1cGxpY2F0ZXMgdGhlIENXVCAiaXNzdWVkIGF0IiB2YWx1ZSBhdCBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FobHN0cm9lbS1vYXV0aC1jYm9yLXdlYi10 b2tlbi0wMCNzZWN0aW9uLTMuMS42LiBUaGUgIm9wZXJhdGlvbiB0aW1lIiB2YWx1ZSBzaG91bGQg YmUgZGVsZXRlZCBmcm9tIHRoaXMgc3BlY2lmaWNhdGlvbiB0byBlbGltaW5hdGUgdGhpcyB1bm5l Y2Vzc2FyeSBkdXBsaWNhdGlvbiAtIG5vdCBqdXN0IHJlbmFtZWQuDQoNCuKAlA0KUmVwbHkgdG8g dGhpcyBlbWFpbCBkaXJlY3RseSBvciB2aWV3IGl0IG9uIEdpdEh1YjxodHRwczovL2dpdGh1Yi5j b20vY29zZS13Zy9jb3NlLWlzc3Vlcy9pc3N1ZXMvMTMjaXNzdWVjb21tZW50LTE2OTY4MDQwMj4u DQo= --_000_BY2PR03MB442117DB523E5446DB50450F5AC0BY2PR03MB442namprd_ 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 IixzZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5N c29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBp bjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0 Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzAwMjA2MDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTYz ODc1MDU0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoy Mjk0Mzg0ODQgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj5ZZXMsIEnigJlsbCBncmFudCB5b3UgdGhhdCB0aGUgY29udGVudCB0 eXBlIHZhbHVlIGJlbG9uZ3MgYmVjYXVzZSBpdOKAmXMgZ2VuZXJhbGx5IHVzZWZ1bCBhbmQgbWV0 YWRhdGEgKjxiPmFib3V0PC9iPiogdGhlIHBheWxvYWQuJm5ic3A7IFdoZXJlYXMsIHRoZSBjcmVh dGlvbiB0aW1lIGZpZWxkDQogaXMgKjxiPnBhcnQ8L2I+KiBvZiB0aGUgcGF5bG9hZC4mbmJzcDsg SXQgYWxzbyBkdXBsaWNhdGVzIHRoZSBDV1QgaXNzdWVkLWF0IGZpZWxkLiZuYnNwOyBJdCBzdGls bCBuZWVkcyB0byBiZSByZW1vdmVkIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZS4mbmJzcDsgTWFya2lu ZyB0aGlzIG9uZSBhcyDigJxjb21wbGV0ZeKAnSBpcyBhbiBpbmNvcnJlY3QgY2F0ZWdvcml6YXRp b24gb2YgdGhlIGlzc3VlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2 MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKaW0gU2NoYWFkIFttYWlsdG86aWV0ZkBhdWd1c3RjZWxs YXJzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDEyLCAyMDE2IDEw OjQyIEFNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBjb3NlQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJFOiBbY29zZS1pc3N1ZXNdIE1vdmUg4oCcY3JlYXRpb24gdGltZeKAnSB2YWx1ZSB0 byB0aGUgcGF5bG9hZCAoIzEzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGNhbm5vdCBhZ3JlZSB3 aXRoIHlvdXIg4oCdYnJpZ2h0IGxpbmUgdGVzdOKAnS4mbmJzcDsgSSBkbyBub3QgYmVsaWV2ZSB0 aGF0IHRoaXMgdGVzdCBtYWtlcyBhbnkgc2Vuc2UgYW5kIEkgZG8gbm90IGJlbGlldmUgdGhhdCB5 b3UgaGF2ZSByZWFsbHkgdGhvdWdodCB0aGUgaW1wbGljYXRpb25zDQogb2YgdGhpcyBydWxlIHRo cm91Z2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDtJZiB0aGlzIGlzIHJlYWxseSB0aGUg cnVsZSB0byBiZSBhcHBsaWVkIHRoZW4gaXQgbWFrZXMgc2Vuc2UgdG8gc2F5IHRoYXQgdGhpcyBz aG91bGQgYmUgYXBwbGllZCB0byBhbGwgb2YgdGhlIGhlYWRlciBmaWVsZHMsIGJ1dCB0aGF0IGlz IG5vdCB3aGF0IHlvdQ0KIGFyZSBkb2luZy4mbmJzcDsgVG8gc2F5IHRoYXQgY3J5cHRvZ3JhcGhp YyBydWxlcyBhcmUgcmVxdWlyZWQgd291bGQgaW1wbHkgdGhhdCB5b3Ugc2hvdWxkIGJlIGFyZ3Vp bmcgdGhhdCB0aGUg4oCcY29udGVudCB0eXBl4oCdIGhlYWRlciBmaWVsZCBzaG91bGQgYWxzbyBi ZSBlbGltaW5hdGVkLiZuYnNwOyBUaGVyZSBhcmUgbm8gY3J5cHRvZ3JhcGhpYyBydWxlcyB0aGF0 IGFyZSBhcHBsaWVkIHRvIHRoaXMgZmllbGQgZWl0aGVyLiZuYnNwOyBZb3UgaGF2ZSBub3QgYmVl biBhcmd1aW5nDQogZm9yIHRoaXMgZmllbGQgdG8gYmUgcmVtb3ZlZC4gPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4y LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBjb25jZXB0IHRoYXQg YW4gYXBwbGljYXRpb24gY291bGQgZGVmaW5lIGEgaGVhZGVyIHBhcmFtZXRlciBidXQgdGhpcyBk b2N1bWVudCBjYW5ub3QgZGVmaW5lIHRoZSBzcGVjIG1lYW5zIHRoYXQgdGhpcyBpcyBub3QgYSBy dWxlIGZvciB0aGUgcmVnaXN0cnksDQogYnV0IGEgcnVsZSBmb3IgdGhlIHNwZWNpZmljYXRpb24u Jm5ic3A7IEhvd2V2ZXIsIHRoZSBpdCBtYWtlcyBjb21wbGV0ZSBzZW5zZSBmb3IgdGhpcyBzcGVj aWZpY2F0aW9uIHRvIGRlZmluZSB0aG9zZSBoZWFkZXIgZmllbGRzIHRoYXQgYSBzaWduaWZpY2Fu dCBwb3J0aW9uIG9mIHRoZSBjb21tdW5pdHkgYmVsaWV2ZXMgdGhhdCBtaWdodCBiZSB1c2VmdWwg Zm9yIGFwcGxpY2F0aW9ucyBzbyB0aGF0IHRoZXkgYXJlIGluIGEgc2luZ2xlIHNwZWNpZmljYXRp b24NCiBhbmQgbGlrZWx5IHRvIGJlIHByb3ZpZGVkIGJ5IGdlbmVyYWwgbGlicmFyaWVzIHJhdGhl ciB0aGFuIGJlaW5nIGluIGEgc2Vjb25kYXJ5IHNwZWNpZmljYXRpb24gdGhhdCBldmVyeWJvZHkg d2lsbCBuZWVkIHRvIGZpbmQgYW5kIHNlZSBpZiBpdCBpcyBpbXBsZW1lbnRlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXMgdGhlIHNwZWNp ZmljYXRpb24gb3V0bGluZXMsIHRoZXJlIGFyZSBjYXNlcyBpbiB0aGlzIGRvY3VtZW50IHdoZXJl IHRoaXMgZmllbGQgY2FuIGJlIHVzZWQuJm5ic3A7IFRvIHdpdCBjb3VudGVyIHNpZ25hdHVyZXMu Jm5ic3A7IFRoZXJlIGFyZSBhIG51bWJlciBvZiBvdGhlcg0KIGNhc2VzIHdoZXJlIHRoaXMgYWxz byBtYWtlcyBzZW5zZSB0aGF0IGFyZSBub3QgY292ZXJlZCBpbiB0aGlzIGRvY3VtZW50IGJlY2F1 c2UgdGhlcmUgZG9lcyBub3Qgc2VlbSB0byBiZSBhbnkgcmVhc29uIHRvIGNvdmVyIHRoZW0gYXMg dGhleSBhcmUgZGVwbG95bWVudCBzcGVjaWZpYy4mbmJzcDsgQnV0IHRoaXMgY291bGQgaW5jbHVk ZSBnYXRld2F5IGFuZCBwcm94eSBzaWduaW5nLiZuYnNwOyBMaXN0IHNlcnZlciBzaWduaW5nIChD b0FQIGhhcyB0aGlzIGNvbmNlcHQNCiBidXQgY2FsbHMgaXQgc29tZXRoaW5nIGRpZmZlcmVudC4p IEFkZGl0aW9uYWxseSwgdGhlIHRpbWUgdGhhdCBhIHN0YXRlbWVudCBpcyBhc3NlcnRlZCBhdCBh bmQgdGhlIHRpbWUgdGhhdCB0aGUgY3J5cHRvZ3JhcGhpYyBvcGVyYXRpb24gaXMgZG9uZSBtYXkg YmUgZGlmZmVyZW50IGV2ZW4gZm9yIGEgQ1dUIHNvIHRoYXQgaWYgdGhpcyBmaWVsZCB3YXMgdXNl ZCwgaXQgbWlnaHQgbm90IGFncmVlIHdpdGggdGhlIGNvbnRlbnQgb2YgdGhlIENXVC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjQuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGNvbmNl cHQgb2Ygc3luY2hyb25pemVkIGNsb2NrcyBpcyBub3Qgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGJl IGRpc21pc3NlZCBvdXQgb2YgaGFuZC4mbmJzcDsgSWYgeW91IGxvb2sgYXQgdGhlIHNlbnNvciBp biBteSBhdW504oCZcyBiYWNreWFyZCwgaXQgaXMgYQ0KIHJlbGF0aXZlbHkgbGFyZ2Ugc2Vuc29y IGFuZCBoYXMgYSBzb2xhciBwYW5lbCB0byBwb3dlciB0aGUgYmF0dGVyeS4mbmJzcDsgVGhpcyBt ZWFucyB0aGF0IGl0IGNvdWxkIGVhc2lseSBoYXZlIGEgY2xvY2sgY29uZmlndXJlZCBhbmQgcG90 ZW50aWFsbHkgZXZlbiBiZSBzeW5jaHJvbml6ZWQuJm5ic3A7IFRoZSBzaXplIG9mIGEgc2Vuc29y IHZhcmllcyBhIGxvdCBzbyB0aGF0IHNvbWUgd2lsbCBiZSBhYmxlIHRvIGhhdmUgdGltZSBhbmQg c29tZSB3aWxsIG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkppbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNaWtlIEpvbmVzIFs8YSBo cmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5tYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEphbnVh cnkgMTEsIDIwMTYgNzo0MyBQTTxicj4NCjxiPlRvOjwvYj4gSmltIFNjaGFhZCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iPmlldGZAYXVndXN0Y2VsbGFycy5jb208 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmNvc2VAaWV0Zi5vcmciPmNv c2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbY29zZS1pc3N1ZXNdIE1v dmUg4oCcY3JlYXRpb24gdGltZeKAnSB2YWx1ZSB0byB0aGUgcGF5bG9hZCAoIzEzKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj5GYWlyIGVub3VnaC4mbmJzcDsgQnV0IHRoZXJl4oCZcyBub3RoaW5nIHN0 b3BwaW5nIHRoZSBzZW5zb3IgYXBwbGljYXRpb24gZnJvbSBkZWZpbmluZyBhIGhlYWRlciBwYXJh bWV0ZXIgdGhhdCBkb2VzIGV4YWN0bHkgd2hhdCBpdCBuZWVkcyB0byBkbywgcmVnaXN0ZXJpbmcg aXQsIGFuZA0KIHVzaW5nLiZuYnNwOyBUaGUg4oCcY3JlYXRpb24gdGltZeKAnSBwYXJhbWV0ZXIg aW1wbGllcyBzeW5jaHJvbml6ZWQgY2xvY2tzLCB3aGljaCBwcm9iYWJseSB0YWtlcyBpdCBvdXQg b2YgYXBwbGljYWJpbGl0eSBpbiB0aGUgc2Vuc29yIHNwYWNlIGFscmVhZHkuJm5ic3A7IFRoZXJl IGFyZSBsb3RzIG9mIGdvb2QgYXBwbGljYXRpb24tc3BlY2lmaWMgY2hvaWNlcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoZSBicmlnaHQgbGluZSB0ZXN0IGZv ciBtZSB0aGF0IHNheXMgdGhhdCB0aGlzIGhlYWRlciBwYXJhbWV0ZXIgZG9lc27igJl0IGJlbG9u ZyBpbiB0aGUgY3J5cHRvIHNwZWMgaXMgdGhhdCB0aGVyZSBhcmUgbm8gY3J5cHRvZ3JhcGhpYyBw cm9jZXNzaW5nIHJ1bGVzIGZvciBpdC4mbmJzcDsNCiBUaGF0IHNheXMgdGhhdCBpdOKAmXMgYXBw bGljYXRpb24gZGF0YSDigJMgbm90IGNyeXB0byBkYXRhLiZuYnNwOyBBbmQgYXMgc3VjaCwgaXQg c2hvdWxkIGJlIGRlZmluZWQgYnkgYXBwbGljYXRpb25zIOKAkyBub3QgdGhlIGNyeXB0byBzcGVj LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+UGxlYXNlIHJlbW92 ZSB0aGlzIHBhcmFtZXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBK aW0gU2NoYWFkIFs8YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSI+bWFpbHRv OmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwg SmFudWFyeSAxMSwgMjAxNiA0OjA3IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDs8 YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmNv c2VAaWV0Zi5vcmciPmNvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBb Y29zZS1pc3N1ZXNdIE1vdmUg4oCcY3JlYXRpb24gdGltZeKAnSB2YWx1ZSB0byB0aGUgcGF5bG9h ZCAoIzEzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHdpbGwgcG9pbnQgb3V0IHRoYXQgdGhpcyBp cyBkZXNpZ25lZCB0byB3cmFwIHRoaW5ncyBvdGhlciB0aGFuIENXVC4mbmJzcDsgSWYgeW91IGFy ZSB3cmFwcGluZyBhIHNlbnNvciByZWFkaW5nIHRoZW4gdGhlcmUgaXMgbm90IGEgQ1dUIGludm9s dmVkIGF0IHRoYXQgcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5KaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWlrZSBKb25lcyBb PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+bWFpbHRvOk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBK YW51YXJ5IDExLCAyMDE2IDEyOjI4IFBNPGJyPg0KPGI+VG86PC9iPiBKaW0gU2NoYWFkICZsdDs8 YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSI+aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86Y29zZUBpZXRmLm9y ZyI+Y29zZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtjb3NlLWlzc3Vl c10gTW92ZSDigJxjcmVhdGlvbiB0aW1l4oCdIHZhbHVlIHRvIHRoZSBwYXlsb2FkICgjMTMpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPkkgaGF2ZSBub3cuJm5ic3A7IFRoaXMgc3RpbGwgZmVlbHMgbGlr ZSB1bm5lY2Vzc2FyeSBkdXBsaWNhdGlvbiBvZiB0aGUNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC13YWhsc3Ryb2VtLWFjZS1jYm9yLXdlYi10b2tlbi0wMCNzZWN0 aW9uLTMuMS42Ij4NCkNCT1IgV2ViIFRva2VuIChDV1QpIOKAnGlhdOKAnSAoaXNzdWVkIGF0KTwv YT4gY2xhaW0gdG8gbWUsIGJ1dCBJ4oCZbSBjdXJpb3VzIHdoYXQgb3RoZXJzIHRoaW5rLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEppbSBTY2hhYWQgWzxhIGhyZWY9Im1h aWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tIj5tYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNv bTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDgsIDIwMTYgNDoxNiBQ TTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpjb3NlQGlldGYub3JnIj5jb3NlQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW2Nvc2UtaXNzdWVzXSBNb3ZlIOKAnGNy ZWF0aW9uIHRpbWXigJ0gdmFsdWUgdG8gdGhlIHBheWxvYWQgKCMxMyk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+RGlkIHlvdSByZWFkIHRoZSBjaGFuZ2UgaW4gdGhlIHRleHQgdGhhdCB3YXMgbWFkZSBh dCB0aGUgc2FtZSB0aW1lPyZuYnNwOyAmbmJzcDsmbmJzcDtJdCBzdGF0ZXMgdGhhdCDigJxUaGUg ZmllbGQgaXMgcHJpbWFyaWx5IGludGVuZGVkIHRvIGJlIHRvIGJlIHVzZWQgZm9yIGNvdW50ZXJz aWduYXR1cmVzLA0KIGhvd2V2ZXIgaXQgY2FuIGFkZGl0aW9uYWxseSBiZSB1c2VkIGZvciByZXBs YXkgZGV0ZWN0aW9uIGFzIHdlbGwu4oCdJm5ic3A7IEl0IGlzIG5vdCBwb3NzaWJsZSB0byBwdXQg dGhlIHRpbWUgZmllbGQgaW4gdGhlIGNvbnRlbnQgZm9yIGEgY291bnRlcnNpZ25hdHVyZSBhcyB0 aGVyZSBpcyBubyBjdXN0b21pemFibGUgY29udGVudCBpbiB0aGF0IGNhc2UuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNaWtlIEpv bmVzIFs8YSBocmVmPSJtYWlsdG86bm90aWZpY2F0aW9uc0BnaXRodWIuY29tIj5tYWlsdG86bm90 aWZpY2F0aW9uc0BnaXRodWIuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg SmFudWFyeSAwNywgMjAxNiA2OjM0IEFNPGJyPg0KPGI+VG86PC9iPiBjb3NlLXdnL2Nvc2UtaXNz dWVzICZsdDs8YSBocmVmPSJtYWlsdG86Y29zZS1pc3N1ZXNAbm9yZXBseS5naXRodWIuY29tIj5j b3NlLWlzc3Vlc0Bub3JlcGx5LmdpdGh1Yi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSmlt IFNjaGFhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iPmlldGZA YXVndXN0Y2VsbGFycy5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2Nvc2Ut aXNzdWVzXSBNb3ZlIOKAnGNyZWF0aW9uIHRpbWXigJ0gdmFsdWUgdG8gdGhlIHBheWxvYWQgKCMx Myk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5DaGFuZ2luZyB0aGUgbmFtZSBkb2VzIG5v dCBhZGRyZXNzIHRoZSBjb3JlIGlzc3VlIHRoYXQgdGhpcyBmaWVsZCBpcyBzb2xlbHkgZm9yIHVz ZSBhcyBkZWZpbmVkIGJ5IHBhcnRpY3VsYXIgYXBwbGljYXRpb25zIGFuZCBoYXMgbm8gYXNzb2Np YXRlZCBDT1NFIHByb2Nlc3NpbmcgcnVsZXMuIFRoYXQgc2F5cyB0aGF0IGl0IGJlbG9uZ3MgaW4g dGhlIENCT1IgV2ViIFRva2VuIGRyYWZ0LCB3aGljaCBkZWZpbmVzIGFwcGxpY2F0aW9uIHBheWxv YWQNCiBmaWVsZHMsIHJhdGhlciB0aGFuIENPU0UgbWVzc2FnZXMgc3BlYy48bzpwPjwvbzpwPjwv cD4NCjxwPlRoaXMgZmllbGQgYWxzbyBkdXBsaWNhdGVzIHRoZSBDV1QgJnF1b3Q7aXNzdWVkIGF0 JnF1b3Q7IHZhbHVlIGF0IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC13YWhsc3Ryb2VtLW9hdXRoLWNib3Itd2ViLXRva2VuLTAwI3NlY3Rpb24tMy4xLjYiPg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhaGxzdHJvZW0tb2F1dGgtY2Jvci13ZWIt dG9rZW4tMDAjc2VjdGlvbi0zLjEuNjwvYT4uIFRoZSAmcXVvdDtvcGVyYXRpb24gdGltZSZxdW90 OyB2YWx1ZSBzaG91bGQgYmUgZGVsZXRlZCBmcm9tIHRoaXMgc3BlY2lmaWNhdGlvbiB0byBlbGlt aW5hdGUgdGhpcyB1bm5lY2Vzc2FyeSBkdXBsaWNhdGlvbiAtIG5vdCBqdXN0IHJlbmFtZWQuPG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0Om5vbmUiPjxz cGFuIHN0eWxlPSJjb2xvcjojNjY2NjY2Ij7igJQ8YnI+DQpSZXBseSB0byB0aGlzIGVtYWlsIGRp cmVjdGx5IG9yIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3NlLXdnL2Nvc2UtaXNzdWVz L2lzc3Vlcy8xMyNpc3N1ZWNvbW1lbnQtMTY5NjgwNDAyIj4NCnZpZXcgaXQgb24gR2l0SHViPC9h Pi48c3BhbiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4i PjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBpZD0iX3gwMDAwX2kxMDI1IiBz cmM9ImNpZDppbWFnZTAwMS5qcGdAMDFEMTY3RDguQTZCQjg4QzAiIGFsdD0iSW1hZ2UgcmVtb3Zl ZCBieSBzZW5kZXIuIj48L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB442117DB523E5446DB50450F5AC0BY2PR03MB442namprd_-- --_004_BY2PR03MB442117DB523E5446DB50450F5AC0BY2PR03MB442namprd_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=332; creation-date="Mon, 15 Feb 2016 18:08:22 GMT"; modification-date="Mon, 15 Feb 2016 18:08:22 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_BY2PR03MB442117DB523E5446DB50450F5AC0BY2PR03MB442namprd_-- From nobody Mon Feb 15 10:19: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 074201ACD0A for ; Mon, 15 Feb 2016 10:19:39 -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 E22k-TF-9-GU for ; Mon, 15 Feb 2016 10:19:37 -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 702531A00E4 for ; Mon, 15 Feb 2016 10:19:37 -0800 (PST) Date: Mon, 15 Feb 2016 10:19:36 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455560376; bh=kCpVsAAok5YNlF/PC1Y8To9WYS2u0g/XVL8OxbaRtm0=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=nMjC8p4CzlmGMfRI+xyJ5zKxQvm0zQzW5D6Q/71gI+wCDQvKvOgNqRQlLx2SN4Sdn dGrgExLbpt2uLY9CCDbqRCErYbhS5dLSConM9rN73gr2DOp+wZQha9Ck4JHtXeKNQB HJYwCMnG62H2APFK1/P2dNqYIkogl7FCSz9pGCT8= From: Mike Jones To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c216b8235a9_5b063f8b100192a06004fc"; 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] Remove example features not implemented in the specification (#15) 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, 15 Feb 2016 18:19:39 -0000 ----==_mimepart_56c216b8235a9_5b063f8b100192a06004fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit It is incorrect to categorize this as being complete, as the sentence in question that Hannes first objected to has not been removed. 4.1 still includes this text: Examples of parameters about the signature would be the algorithm and key used to create the signature, when the signature was created, and a counter- signature. Please remove it. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/15#issuecomment-184334424 ----==_mimepart_56c216b8235a9_5b063f8b100192a06004fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

It is incorrect to categorize this as being complete, as the sentence in question that Hannes first objected to has not been removed. 4.1 still includes this text:

Examples of
parameters about the signature would be the algorithm and key used to
create the signature, when the signature was created, and a counter-
signature.

Please remove it.

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

----==_mimepart_56c216b8235a9_5b063f8b100192a06004fc-- From nobody Mon Feb 15 10:23: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 AADC61ACD3E for ; Mon, 15 Feb 2016 10:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.608 X-Spam-Level: X-Spam-Status: No, score=-5.608 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, 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 VQFyhSJWbKIn for ; Mon, 15 Feb 2016 10:23:42 -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 D66411ACD40 for ; Mon, 15 Feb 2016 10:23:41 -0800 (PST) Date: Mon, 15 Feb 2016 10:23:34 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455560614; bh=RmMGH2v/JZt8IEBehNHP/7F6qcyUn/u67LKZTgPsgoI=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XAOtiBgYZZ2ls2HExn29Rm9euzQJyHdltr6DKG/2WAjPIEzRImZ+0F3/tpIjkcaZm LbPHoPD8GZldMRE43a+fWAb+onnQM5gxPjeyTqeeQfR1g78q73hxn6H+s3Cki/8qHJ 3/8PCu4jZMaFp8TtJTbM7r9L/3d88rTlwiGZT/d8= From: Mike Jones To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c217a635a38_14143f87b8f992bc7135cc"; 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] =?utf-8?b?W2Nvc2UtaXNzdWVzXSBSZXN0b3JlIOKAnHVzZeKAnSBDT1NF?= =?utf-8?q?_key_parameter_description_=28=2323=29?= 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, 15 Feb 2016 18:23:43 -0000 ----==_mimepart_56c217a635a38_14143f87b8f992bc7135cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit For public keys, having the simple two-valued "use" parameter is substantially simpler than requiring the use of an array-valued "key_ops" parameter. This is the approach used by XMLDSIG/XMLENC and by many JOSE profiles. Given that public keys are the common case, it's one we should be optimizing for. Given that this action has not been done, it is incorrect to categorize this issue as "complete". As with some other open issues, it would be useful to have more working group members than just Jim and myself weighing in on this. Thanks. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/23#issuecomment-184335496 ----==_mimepart_56c217a635a38_14143f87b8f992bc7135cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

For public keys, having the simple two-valued "use" parameter is substantially simpler than requiring the use of an array-valued "key_ops" parameter. This is the approach used by XMLDSIG/XMLENC and by many JOSE profiles. Given that public keys are the common case, it's one we should be optimizing for.

Given that this action has not been done, it is incorrect to categorize this issue as "complete". As with some other open issues, it would be useful to have more working group members than just Jim and myself weighing in on this. Thanks.

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

----==_mimepart_56c217a635a38_14143f87b8f992bc7135cc-- From nobody Mon Feb 15 10:27: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 410C11A9252 for ; Mon, 15 Feb 2016 10:27:18 -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 vJ98cY3BDt1R for ; Mon, 15 Feb 2016 10:27:14 -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 4493A1A924B for ; Mon, 15 Feb 2016 10:27:14 -0800 (PST) Date: Mon, 15 Feb 2016 10:27:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455560833; bh=LhecxpV+RA8dtaOeEwZ6L0uLbGUlyNuVoKEvxd0y9Tc=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=P4Wjo+IWDTmkIm1An/mOQpqlNSzf9yvcUV3NXHoL+waXa61iwdGhKCjpgLaZ2fyqI j3Rd6AZygKU5SJWBL3XfAzg1H58zt5BrqQAtH2xiAD73nHH7helqHb/AXZuM/DuhuB N9Tsvlj7qbvAXPUVSyDDAsvOdukScTGOlhVaPZ0g= From: Mike Jones To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c21881971eb_eaa3fc7dda5b2b8876352"; 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] Acknowledgements Missing (#25) 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, 15 Feb 2016 18:27:18 -0000 ----==_mimepart_56c21881971eb_eaa3fc7dda5b2b8876352 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit While an Acknowledgements section has been added, all it says is "This document is a product of the COSE working group of the IETF." This does not satisfy the intent of having an Acknowledgments section, which is to acknowledge by name those who have made significant contributions to the specification. This is not only a standard practice and a common courtesy - it's the right thing to do. Until this is done, it is incorrect to categorize this issue as "complete". --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/25#issuecomment-184336327 ----==_mimepart_56c21881971eb_eaa3fc7dda5b2b8876352 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

While an Acknowledgements section has been added, all it says is "This document is a product of the COSE working group of the IETF." This does not satisfy the intent of having an Acknowledgments
section, which is to acknowledge by name those who have made significant contributions to the specification. This is not only a standard practice and a common courtesy - it's the right thing to do.

Until this is done, it is incorrect to categorize this issue as "complete".

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

----==_mimepart_56c21881971eb_eaa3fc7dda5b2b8876352-- From nobody Mon Feb 15 10:30:49 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 27B871ACD93 for ; Mon, 15 Feb 2016 10:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 O0Xqx_rHbvvf for ; Mon, 15 Feb 2016 10:30:35 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0135.outbound.protection.outlook.com [207.46.100.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA81A1ACD83 for ; Mon, 15 Feb 2016 10:30:35 -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=Ro+kyO4Iehq1QXcoEGQkYI0IIWFzP7BmU0ja34AAcRI=; b=I1YAVhSJ5ADhy0gMpdi4m1xMBLNr3qBtqzBQhNmn5Yl+HlWO0xTdfeWFbn0+ALVMLw1oGmZWDvaIhVNTB+5wuYksQxRr0PbTtOYEcv5BtJFTbveAXLHUCBgwUadm3h7hIFL2L9GPpLBieGNKKIvy3ob1iZgkJnDdiTRkDgCp4WQ= 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.409.15; Mon, 15 Feb 2016 18:30: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.0409.017; Mon, 15 Feb 2016 18:30:34 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [cose-issues] Require publicly visible stable specifications for IANA registrations (#39) Thread-Index: AQHRPFCAKn53T0H57U6o+cohh4mD05725P3ggABIBQCANpfD4A== Date: Mon, 15 Feb 2016 18:30:34 +0000 Message-ID: References: <015801d13c50$1d1e24a0$575a6de0$@augustcellars.com> <042901d14cd2$d2338550$769a8ff0$@augustcellars.com> In-Reply-To: <042901d14cd2$d2338550$769a8ff0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: f8fe57a7-38d7-4635-f057-08d3363617d2 x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:KDFSqMbhiIzA7RMEbrJJ9I7A1KGlSZUpIymoyyAotGobQFxR6xBcZdgperfDD+EUv6oN54vK/bAKyqdDflftIWMD55HJwGAep0z5xl/zMNgXOZ/VprNaoSA10+EA7/szjgwj9IT7sbBN8qTZ7RRzCA==; 24:eA9U/BOfH2htSTHFM/psKKVwxRj/HGbXgPnMJq/QEZfG517bUH0sf1fwb43xfxuahhHfRXVtoNq8LMN2sP16pSF4smG048dCOmmYQd9k0zQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 08534B37A7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(189998001)(19580395003)(19580405001)(74316001)(106116001)(99286002)(5004730100002)(86362001)(8990500004)(86612001)(5008740100001)(76576001)(87936001)(11100500001)(110136002)(5001960100002)(15395725005)(5002640100001)(10400500002)(33656002)(5005710100001)(1220700001)(2906002)(1096002)(102836003)(3846002)(10290500002)(66066001)(40100003)(5003600100002)(92566002)(122556002)(15975445007)(93886004)(77096005)(76176999)(2900100001)(54356999)(50986999)(6116002)(586003)(10090500001)(4326007); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 15 Feb 2016 18:30:34.3799 (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, 15 Feb 2016 18:30:44 -0000 SWYgYSBtZXNzYWdlIHNlbnQgYnkgeW91ciBzeXN0ZW0gdG8gbXkgc3lzdGVtIHJlcXVpcmVzIGlu dGVyb3BlcmFiaWxpdHkgb24gdGhlIHVzZSBvZiBhIGNvZGUgcG9pbnQsIHRoZW4gaXQgc2hvdWxk IGJlIHJlZ2lzdGVyZWQgYW5kIGEgcHVibGljIGRlc2NyaXB0aW9uIHNob3VsZCBiZSBhdmFpbGFi bGUgb2Ygd2hhdCBpdCBtZWFucywgd2hpY2ggaXMgbmVjZXNzYXJ5IGZvciBpbnRlcm9wZXJhYmls aXR5IGFtb25nIGFmZmlsaWF0ZWQgcGFydGllcy4NCg0KQXNraW5nIHBlb3BsZSB0byBkZWZpbmUg d2hhdCBhIGNvZGUgcG9pbnQgbWVhbnMgYXQgdGhlIHRpbWUgaXQncyBiZWluZyByZWdpc3RlcmVk IGlzIGJ5IG5vIG1lYW5zIG9uZXJvdXMuDQoNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBKaW0gU2NoYWFkIFttYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbV0gDQpTZW50OiBNb25kYXksIEphbnVhcnkgMTEsIDIwMTYgNDo0OCBQTQ0KVG86IE1pa2Ug Sm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBjb3NlQGlldGYub3JnDQpT dWJqZWN0OiBSRTogW2Nvc2UtaXNzdWVzXSBSZXF1aXJlIHB1YmxpY2x5IHZpc2libGUgc3RhYmxl IHNwZWNpZmljYXRpb25zIGZvciBJQU5BIHJlZ2lzdHJhdGlvbnMgKCMzOSkNCg0KU28geW91IGFy ZSBzYXlpbmcgdGhhdCB0aGVyZSBpcyBub3QgYSBwcm9ibGVtIGFzIGxvbmcgYXMgd2UgZG9uJ3Qg cmVnaXN0ZXIgdGhlIGZhY3QgdGhhdCB3ZSBhcmUgdXNpbmcgYSBjb2RlIHBvaW50IGZvciBpZGVu dGlmeWluZyB0aGUgcHJpdmF0ZSBpdGVtIHdlIGFyZSB1c2luZy4gIEV2ZW4gdGhvdWdoIHdlIG1p Z2h0IGJlIHVzaW5nIHRoZSBzYW1lIGNvZGUgcG9pbnQgdG8gbWVhbiBkaWZmZXJlbnQgdGhpbmdz IGFuZCBhIG1lc3NhZ2Ugc2V0IGJ5IG15IHN5c3RlbSBtaWdodCBiZSByZWNlaXZlZCBieSB5b3Vy IHN5c3RlbS4NCg0KVGhlIG5lZWQgZm9yIHJlZ2lzdHJhdGlvbiBpcyBiZWNhdXNlIHRoZXJlIGlz IG5vdCB0aGUgYWJpbGl0eSB0aGF0IEpPU0UgaGFzIHdoZXJlIHRoZXJlIGlzIGEgc3RhdGVtZW50 IGFib3V0IHRyeWluZyB0byB1c2UgcHJpdmF0ZSBpZGVudGlmaWVycyB0aGF0IGFyZSBzb21laG93 IHNjb3BlZCB0byBiZSBwcml2YXRlLiAgVGhlIHdvcmxkIG9mIGlkZW50aWZpZXJzIGZvciBDT1NF IG1hcHMgY2xvc2VyIHRvIHRoYXQgb2YgdGhlIHB1YmxpYyBidXQgdW5yZWdpc3RlcmVkIHdvcmxk IG9mIEpPU0UuDQoNCkppbQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IE1pa2UgSm9uZXMgW21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb21dDQo+IFNlbnQ6 IE1vbmRheSwgSmFudWFyeSAxMSwgMjAxNiAxMjozNiBQTQ0KPiBUbzogSmltIFNjaGFhZCA8aWV0 ZkBhdWd1c3RjZWxsYXJzLmNvbT4NCj4gQ2M6IGNvc2VAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6 IFtjb3NlLWlzc3Vlc10gUmVxdWlyZSBwdWJsaWNseSB2aXNpYmxlIHN0YWJsZSANCj4gc3BlY2lm aWNhdGlvbnMgZm9yIElBTkEgcmVnaXN0cmF0aW9ucyAoIzM5KQ0KPiANCj4gSSBkb24ndCB0aGlu ayB0aGF0IHJlZ2lzdGVyaW5nIENPU0UgdmFsdWVzIHdpdGhvdXQgbWFraW5nIGEgDQo+IHNwZWNp ZmljYXRpb24gcHVibGljbHkgYXZhaWxhYmxlIHNvIHRoYXQgdGhlIHJlZ2lzdGVyZWQgdmFsdWUg Y2FuIGJlIA0KPiB1bmRlcnN0b29kIGFuZCBoYXZpbmcgcHJpdmF0ZSBoZWFkZXIgcGFyYW1ldGVy IG5hbWVzIGluIEpPU0UsIHdoaWNoIA0KPiBhcmUgbm90IHJlZ2lzdGVyZWQsIGFyZSBlcXVpdmFs ZW50LiAgVGhlIGRpZmZlcmVuY2UgaXMgdGhhdCBpbiB0aGUgDQo+IGN1cnJlbnQgQ09TRSBtZXRo b2RvbG9neSwgaXQncyBwb3NzaWJsZSB0byBoYXZlIHJlZ2lzdGVyZWQgdmFsdWVzIGJ1dCANCj4g bm8gd2F5IGZvciBpbXBsZW1lbnRlcnMgdG8gZm9sbG93IGEgbGluayBmcm9tIHRoZSByZWdpc3Ry eSB0byANCj4gdW5kZXJzdGFuZCB3aGF0IHRoZSBtZWFuaW5nIG9mIHRoZSB2YWx1ZSBpcy4gIElu IEpPU0UsIGlmIGl0J3MgDQo+IHJlZ2lzdGVyZWQsIHRoZXJlJ3MgYWx3YXlzIGEgbGluayBmcm9t IHRoZSByZWdpc3RyeSB0byB0aGUgZGVmaW5pdGlvbi4gIFRoYXQgc2VlbXMgYSBsb3QgbW9yZSBj b25zaXN0ZW50IGFuZCB1c2VmdWwgdG8gbWUsIGhlbmNlIG15IHJlcXVlc3QgZm9yIHRoZSBjaGFu Z2UuDQo+IA0KPiBJJ20gZmluZSB3aXRoIHByaXZhdGUgdmFsdWVzIGZvciBwcml2YXRlIHVzYWdl cy4gIEp1c3QgZG9uJ3QgcmVnaXN0ZXIgdGhlbS4NCj4gUmVnaXN0cmF0aW9ucyBzaG91bGQgYWxs IGJlIHNwZWNpZmljYXRpb24tcmVxdWlyZWQuDQo+IA0KPiAJCQkJLS0gTWlrZQ0KPiANCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmltIFNjaGFhZCBbbWFpbHRvOmlldGZA YXVndXN0Y2VsbGFycy5jb21dDQo+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMjEsIDIwMTUgNDoz MiBQTQ0KPiBUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KPiBD YzogY29zZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW2Nvc2UtaXNzdWVzXSBSZXF1aXJlIHB1 YmxpY2x5IHZpc2libGUgc3RhYmxlIA0KPiBzcGVjaWZpY2F0aW9ucyBmb3IgSUFOQSByZWdpc3Ry YXRpb25zICgjMzkpDQo+IA0KPiBNaWtlLA0KPiANCj4gSSB3YXMgd29uZGVyaW5nIGlmIHlvdSBj b3VsZCBhZGRyZXNzIHdoYXQgbWlnaHQgYmUgc2VlbiBhcyBhIGNoYW5nZSBpbiANCj4geW91ciBh dHRpdHVkZSB0byB0aGlzIG92ZXIgdGltZS4NCj4gDQo+IFRoZSBKT1NFIHNwZWNpZmljYXRpb25z IGFsbG93IGZvciBhIHByaXZhdGVseSBkZWZpbmVkIGhlYWRlciBmaWVsZCB0byBiZSBjcmVhdGVk Lg0KPiANCj4gU29tZXRoaW5nIHNpbWlsYXIgdG8gdGhlIGN1cnJlbnQgQ09TRSBhbGxvY2F0aW9u cyBpcyBkb25lIGluIHRoZSBKT1NFIA0KPiBkb2N1bWVudHMgYnkgdGhlIGZvbGxvd2luZzoNCj4g DQo+IA0KPiBSZWdpc3RlcmVkIEhlYWRlciBQYXJhbWV0ZXIgTmFtZXMgaW4gSk9TRTogIFRoaXMg Y29ycmVzcG9uZHMgdG8gdGhlIA0KPiBnZW5lcmFsIGFyZWEgb2YgU3BlY2lmaWNhdGlvbiBSZXF1 aXJlZCBhc3NpZ25tZW50IGFyZWEgb2YgQ09TRSANCj4gZG9jdW1lbnRzLiAgSSBub3RlIHRoYXQg YWx0aG91Z2ggYSByZWZlcmVuY2UgdG8gYSBkb2N1bWVudCBpcyANCj4gcmVxdWlyZWQsIGl0IGlt cGxpY2l0bHkgYnV0IGRvZXMgbm90IGV4cGxpY2l0bHkgcmVxdWlyZSB0aGF0IHRoZSBkb2N1bWVu dCBiZSBwdWJsaWNseSBhdmFpbGFibGUuDQo+IA0KPiBQdWJsaWMgSGVhZGVyIFBhcmFtZXRlciBO YW1lcyBpbiBKT1NFOiBUaGlzIGNvcnJlc3BvbmQgdG8gdGhlIHNldCBvZiANCj4gZmlyc3QtIGNv bWUsIGZpcnN0IHNlcnZlIGFzc2lnbm1lbnQgYXJlYSBvZiBDT1NFIGRvY3VtZW50cy4gIEpPU0Ug DQo+IGRlYWxzIHdpdGggdGhpcyBieSBzYXlpbmcgdGhhdCBpdCBzaG91bGQgYmUgY29sbGlzaW9u IHJlc2lzdGFudCBieSANCj4gcHJlZml4aW5nIChvciBzb21lIG90aGVyIG1ldGhvZCkgdG8gbWFr ZSB0aGUgbmFtZSBzdGF0aXN0aWNhbGx5IA0KPiB1bmlxdWUuICBGb3IgQ09TRSBpdCB3b3VsZCBu b3QgYmUgcG9zc2libGUgdG8gaGF2ZSBhbnkgZGVncmVlIG9mIA0KPiB1bmlxdWVuZXNzIG9mIHRo ZSBoZWFkZXJzIGluIHRoZSBzYW1lIHdheSB3aGlsZSBzdGlsbCBtYWludGFpbmluZyB0aGUgDQo+ IGRlc2lyZSB0byBoYXZlIHZlcnkgc2hvcnQgaWRlbnRpZmllcnMuICBUaGVyZSBpcyBhIGJpZyBk aWZmZXJlbmNlIGluIA0KPiBzaXplIGJldHdlZW4gImh0dHA6Ly9leGFtcGxlLm9yZy9DT1NFL2Zv b2JhciIgYW5kIDB4MTAwMDAwIHdoZW4gZG9pbmcgdGhlIGVuY29kaW5ncyBpbiBDQk9SLg0KPiAN Cj4gUHJpdmF0ZSBIZWFkZXIgUGFyYW1ldGVyIE5hbWVzIGluIEpPU0U6ICBUaGlzIGNvcnJlc3Bv bmRzIHRvIHRoZSANCj4gcHJpdmF0ZSByZWdpc3RyeSBhc3NpZ25tZW50IGFyZWEgb2YgQ09TRSBk b2N1bWVudHMuDQo+IA0KPiANCj4gSXQgd291bGQgYXBwZWFyIGZyb20gdGhpcyB0aGF0IHRoZXJl IGlzIGFuIGltcGxpY2l0IHJlZ2lzdHJ5IGFyZWEgZm9yIA0KPiBKT1NFIHdoaWNoIGFsbG93cyBm b3IgYSBzZWN0aW9uIGhlYWRlciBwYXJhbWV0ZXJzIHdoaWNoIGRvZXMgbm90IGhhdmUgDQo+IHB1 YmxpY2x5IGF2YWlsYWJsZSBzcGVjaWZpY2F0aW9ucyB3aGVuIGltcGxpY2l0bHkgcmVnaXN0ZXJl ZC4gIFRvIHdpdCwgDQo+IHRoZSBQdWJsaWMgSGVhZGVyIFBhcmFtZXRlciBOYW1lcy4NCj4gDQo+ IEkgYW0gbm90IHN1cmUgaWYgdGhpcyByZWFsbHkgcmVwcmVzZW50cyBhIGNoYW5nZSBpbiB5b3Vy IG9waW5pb25zIG9yIA0KPiBpZiB5b3UgaGF2ZSBqdXN0IG5vdCBjb25zaWRlcmVkIHRoZXNlIGFz IGJlaW5nIGVxdWl2YWxlbnQuDQo+IA0KPiBKaW0NCj4gDQoNCg0K From nobody Mon Feb 15 10:31: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 77D371A90E0 for ; Mon, 15 Feb 2016 10:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 WnihXivdRFWe for ; Mon, 15 Feb 2016 10:31:55 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED7A1A8AC5 for ; Mon, 15 Feb 2016 10:31: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=QYWvmb4zBLVdphjaap+wFXk9JsUlL9kRzCdNz7YZJIM=; b=koTYq5lrhwMebDaG45PhIXoBtx8ls4GQGXcPfeEOMqvP4VLmKxFF6MKC3RLDC2OqwHIHbT8wwF4L+n3R8ueqL+ZWzVSZR2b2kby+lbDdVlVjzt9CV4sBEdgW6WKEPClB0cy8BwQ2VZZ3mskVYwxY6ou56Vm+o8MOQXH2k4RLX58= 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.409.15; Mon, 15 Feb 2016 18:31:52 +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.0409.017; Mon, 15 Feb 2016 18:31:51 +0000 From: Mike Jones To: Mike Jones , Jim Schaad Thread-Topic: [cose-issues] Require publicly visible stable specifications for IANA registrations (#39) Thread-Index: AQHRPFCAKn53T0H57U6o+cohh4mD05725P3ggABIBQCANpfD4IAAAK/A Date: Mon, 15 Feb 2016 18:31:51 +0000 Message-ID: References: <015801d13c50$1d1e24a0$575a6de0$@augustcellars.com> <042901d14cd2$d2338550$769a8ff0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: bb0c9f93-e98c-477c-d1f8-08d3363645c6 x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:T2riUZeGcKr0j57cpMo6iwqMiQTLafqSwJ2a4TjBaH9kU+ExtaNVotHMTJ0KUKbCPLfSNcNotYlujsiSGvobbOsQgjZq9WhTPVMkbBLX7egrmV+4RFl6w+8zW5aw5QLdc5dZYHIslFol9yDLyRMoNA==; 24:fNSBcOFpbYI2nV1DCUFYmlfMIZh9wjFjBHcYJwCW3UabRwPQoFHAA8PpsCa1iy/DxemIBwIDKRZeX9viBvgufsCk2bPuAakBAdMTCghR7cE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 08534B37A7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(13464003)(189998001)(19580395003)(19300405004)(19580405001)(74316001)(106116001)(99286002)(5004730100002)(86362001)(8990500004)(86612001)(5008740100001)(19617315012)(76576001)(2421001)(5001770100001)(87936001)(16236675004)(5001960100002)(15395725005)(19625215002)(5002640100001)(10400500002)(33656002)(5005710100001)(2561002)(790700001)(1220700001)(2906002)(1096002)(102836003)(3846002)(10290500002)(66066001)(40100003)(5003600100002)(92566002)(122556002)(15975445007)(93886004)(77096005)(76176999)(2900100001)(54356999)(50986999)(6116002)(586003)(10090500001)(4326007); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442E15DFA795B5FB84A88E7F5AC0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2016 18:31:51.4601 (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, 15 Feb 2016 18:31:58 -0000 --_000_BY2PR03MB442E15DFA795B5FB84A88E7F5AC0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry - typo. I should have written "... which is necessary for interopera= bility among non-affiliated parties". -----Original Message----- From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Monday, February 15, 2016 10:31 AM To: Jim Schaad Cc: cose@ietf.org Subject: Re: [COSE] [cose-issues] Require publicly visible stable specifica= tions for IANA registrations (#39) If a message sent by your system to my system requires interoperability on = the use of a code point, then it should be registered and a public descript= ion should be available of what it means, which is necessary for interopera= bility among affiliated parties. Asking people to define what a code point means at the time it's being regi= stered is by no means onerous. -- Mike -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, January 11, 2016 4:48 PM To: Mike Jones > Cc: cose@ietf.org Subject: RE: [cose-issues] Require publicly visible stable specifications f= or IANA registrations (#39) 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 diff= erent things and a message set by my system might be received by your syste= m. 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 ar= e somehow scoped to be private. The world of identifiers for COSE maps clo= ser 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) > > 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. T= hat seems a lot more consistent and useful to me, hence my request for the = change. > > I'm fine with private values for private usages. Just don't register the= m. > Registrations should all be specification-required. > > -- Mike > > -----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) > > Mike, > > I was wondering if you could address what might be seen as a change in > your attitude to this over time. > > The JOSE specifications allow for a privately defined header field to be = created. > > Something similar to the current COSE allocations is done in the JOSE > documents by the following: > > > 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. > > 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. > > Private Header Parameter Names in JOSE: This corresponds to the > private registry assignment area of COSE documents. > > > 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. > > I am not sure if this really represents a change in your opinions or > if you have just not considered these as being equivalent. > > Jim > _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose --_000_BY2PR03MB442E15DFA795B5FB84A88E7F5AC0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry - typo.  I should have written ".= .. which is necessary for interoperability among non-affiliated parties".

 =

-----Original Message-----
From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Monday, February 15, 2016 10:31 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: cose@ietf.org
Subject: Re: [COSE] [cose-issues] Require publicly visible stable specifica= tions for IANA registrations (#39)

 

If a message sent by your system to my system req= uires interoperability on the use of a code point, then it should be regist= ered and a public description should be available of what it means, which i= s necessary for interoperability among affiliated parties.

 

Asking people to define what a code point means a= t the time it's being registered is by no means onerous.

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            -- Mik= e

 

-----Original Message-----

From: Jim Schaad [mailto:iet= f@augustcellars.com]

Sent: Monday, January 11, 2016 4:48 PM=

To: Mike Jones <Mich= ael.Jones@microsoft.com>

Cc: cose@ietf.org

Subject: RE: [cose-issues] Require publicly visib= le stable specifications for IANA registrations (#39)

 

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 ident= ifying the private item we are using.  Even though we might be using t= he 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 p= rivate identifiers that are somehow scoped to be private.  The world o= f 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 <ietf= @augustcellars.com>

> Cc: cose@ietf.org

> Subject: RE: [cose-issues] Require publicly = visible stable

> specifications for IANA registrations (#39)<= o:p>

>

> I don't think that registering COSE values w= ithout making a

> specification publicly available so that the= registered value can be

> understood and having private header paramet= er names in JOSE, which

> are not registered, are equivalent.  Th= e difference is that in the

> current COSE methodology, it's possible to h= ave registered values but

> no way for implementers to follow a link fro= m the registry to

> understand what the meaning of the value is.=   In JOSE, if it's

> registered, there's always a link from the r= egistry to the definition.  That seems a lot more consistent and usefu= l to me, hence my request for the change.

>

> I'm fine with private values for private usa= ges.  Just don't register them.

> Registrations should all be specification-re= quired.

>

>        &n= bsp;            = ;            &n= bsp;            = ;         -- Mike

>

> -----Original Message-----

> From: Jim Schaad [mailt= o:ietf@augustcellars.com]

> Sent: Monday, December 21, 2015 4:32 PM=

> To: Mike Jones <Michael.Jones@microsoft.com>

> Cc: cose@ietf.org

> Subject: RE: [cose-issues] Require publicly = visible stable

> specifications for IANA registrations (#39)<= o:p>

>

> Mike,

>

> I was wondering if you could address what mi= ght be seen as a change in

> your attitude to this over time.<= /p>

>

> The JOSE specifications allow for a privatel= y defined header field to be created.

>

> Something similar to the current COSE alloca= tions is done in the JOSE

> documents by the following:

>

>

> Registered Header Parameter Names in JOSE:&n= bsp; This corresponds to the

> general area of Specification Required assig= nment area of COSE

> documents.  I note that although a refe= rence to a document is

> required, it implicitly but does not explici= tly require that the document be publicly available.

>

> 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 possi= ble to have any degree of

> uniqueness of the headers in the same way wh= ile still maintaining the

> desire to have very short identifiers. = There is a big difference in

> size between "htt= p://example.org/COSE/foobar" and 0x100000 when doing the en= codings in CBOR.

>

> Private Header Parameter Names in JOSE: = ; This corresponds to the

> private registry assignment area of COSE doc= uments.

>

>

> It would appear from this that there is an i= mplicit registry area for

> JOSE which allows for a section header param= eters which does not have

> publicly available specifications when impli= citly registered.  To wit,

> the Public Header Parameter Names.

>

> I am not sure if this really represents a ch= ange in your opinions or

> if you have just not considered these as bei= ng equivalent.

>

> Jim

>

 

 

_______________________________________________

COSE mailing list

COSE@ietf.org

https://www.iet= f.org/mailman/listinfo/cose

--_000_BY2PR03MB442E15DFA795B5FB84A88E7F5AC0BY2PR03MB442namprd_-- From nobody Mon Feb 15 10:32:28 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 D2AD51A8AC5 for ; Mon, 15 Feb 2016 10:32: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 SkdZwCbLJjop for ; Mon, 15 Feb 2016 10:32:25 -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 B9BAA1A8FD4 for ; Mon, 15 Feb 2016 10:32:25 -0800 (PST) Date: Mon, 15 Feb 2016 10:32:25 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455561145; bh=97mxGziL33ZhSmpmXv4EOb4m3IuCQQd68ZfMnZGh6yU=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=cAgPcZH3ZnM/lu7oQk9q/pSoQKxYBWMTc+t0hGYvc0Q+CraO/lM7k3VKEKMz8wh4W dqGSOtR0h6nvOcVnPT9GSh6kR3eipCnyBdbhMN8QJ/e1Jti3XSOcBF4ATp548dYdAs HmXLpJQsa+I94InLa0csqSGT47SJupJPeEwlQnKU= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c219b916aa0_4e113fdd85a512a0537796"; 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] =?utf-8?b?W2Nvc2UtaXNzdWVzXSBSZXN0b3JlIOKAnHVzZeKAnSBDT1NF?= =?utf-8?q?_key_parameter_description_=28=2323=29?= 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, 15 Feb 2016 18:32:27 -0000 ----==_mimepart_56c219b916aa0_4e113fdd85a512a0537796 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #23. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/23#event-551069007 ----==_mimepart_56c219b916aa0_4e113fdd85a512a0537796 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #23.

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

----==_mimepart_56c219b916aa0_4e113fdd85a512a0537796-- From nobody Mon Feb 15 10:32:48 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 6B1C91A9104 for ; Mon, 15 Feb 2016 10:32:47 -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 gycj8508WVYK for ; Mon, 15 Feb 2016 10:32:42 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext8.iad.github.net [192.30.252.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077ED1A90F6 for ; Mon, 15 Feb 2016 10:32:42 -0800 (PST) Date: Mon, 15 Feb 2016 10:32:41 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455561161; bh=Y6rA1y1UvFVv4uQ3o5jsx+Q1g13PsVWG9klClWoffc0=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=N9McA+AXWwvnDCYrpq0ctvgjLOdIVkyj4J6zpw3JxeDZU+4wnm6NDUHwOV6Ls5kPf LbSJ7XkDufXVi2oCyBLSexGfTrxN1HuUOGnpAfaoGt+Snlmwx9ak7FdPjOB2hUdgON IqaVik7AccE+yj2x6LPYJkfDBFvs02aDPBlnXhV0= From: Mike Jones To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c219c944d5f_14293f87b8f992bc1612a4"; 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, 15 Feb 2016 18:32:47 -0000 ----==_mimepart_56c219c944d5f_14293f87b8f992bc1612a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit If a message sent by your system to my system requires interoperability on the use of a code point, then it should be registered and a public description should be available of what it means, which is necessary for interoperability among non-affiliated parties. Asking people to define what a code point means at the time it's being registered is by no means onerous. Since this action has not been taken, it is incorrect to categorize this issue as "complete". Also, like other issues, it would be useful to have others weigh in beyond Jim and myself. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/39#issuecomment-184339104 ----==_mimepart_56c219c944d5f_14293f87b8f992bc1612a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

If a message sent by your system to my system requires interoperability on the use of a code point, then it should be registered and a public description should be available of what it means, which is necessary for interoperability among non-affiliated parties.

Asking people to define what a code point means at the time it's being registered is by no means onerous.

Since this action has not been taken, it is incorrect to categorize this issue as "complete". Also, like other issues, it would be useful to have others weigh in beyond Jim and myself.

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

----==_mimepart_56c219c944d5f_14293f87b8f992bc1612a4-- From nobody Mon Feb 15 10:33: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 ADFB31A9233 for ; Mon, 15 Feb 2016 10:33:12 -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 sVodlVITKQ9Q for ; Mon, 15 Feb 2016 10:33:11 -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 E70B21A9124 for ; Mon, 15 Feb 2016 10:33:10 -0800 (PST) Date: Mon, 15 Feb 2016 10:33:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455561190; bh=gAkfKoJZoEfqOlmii9zYKJ9qNxvFysKekz/TnZtWs+s=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bIph/EKcf9dF2UXKsjdn7j8ztmrI7vdJX7G3fE9sEGRnGNwlvvmiXB6B0kPiXDZhc 5WD8zZSnY6/WIwi2rTJJiMX4XUs23+DHcjSHPGAi4sUL70DKOEYsLXSk1jj2BUihJn 1S/XmKmyns68GDM2YACXk7VNqY+xPEeW6xflZqlo= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c219e632e7d_eb33fc7dda5b2b87401a5"; 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] Remove example features not implemented in the specification (#15) 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, 15 Feb 2016 18:33:12 -0000 ----==_mimepart_56c219e632e7d_eb33fc7dda5b2b87401a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit These are all attributes that are defined in the document. It is therefore completed --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/15#issuecomment-184339334 ----==_mimepart_56c219e632e7d_eb33fc7dda5b2b87401a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

These are all attributes that are defined in the document. It is therefore completed

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

----==_mimepart_56c219e632e7d_eb33fc7dda5b2b87401a5-- From nobody Mon Feb 15 10:37: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 C51811A8A0C for ; Mon, 15 Feb 2016 10:37:41 -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 yaYtTmn27n2a for ; Mon, 15 Feb 2016 10:37:39 -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 B53391A0033 for ; Mon, 15 Feb 2016 10:37:38 -0800 (PST) Date: Mon, 15 Feb 2016 10:37:37 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455561458; bh=J+UoPq7Dxzq/SvnZV2rSfnzQ+5eVaCW9EtoJKa0dZB0=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bL+2OhhD2EDU/f5RWuKEXlnV28Gbj7RYCuzJ+NnAnRVcvR5UX+DBnt6aWkkShSemH schhbpkZ1DnyvuOhcTb4+evEV9S7X+Wx3NCY1VRX/gmzEg0N6pi3To+bqDEf3mtvl1 XnqPnNRo8bMzVT+KZ1xNCO7scHbDPXYHx87xOXHs= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c21af1ed0bb_79ee3fc7dda5b2b834452e"; 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] 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, 15 Feb 2016 18:37:41 -0000 ----==_mimepart_56c21af1ed0bb_79ee3fc7dda5b2b834452e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit If a message is sent from my system to your system and it is not required that you understand the attribute, then it is necessary that you do not define an attribute at the same code point and it is not necessary that you understand this code point. Information that is company private should be able to remain company private and it should be able to be updated at any time by the company without having to publish new documents. This is what this allows for and is a totally reasonable issue. This corresponds to using the public header parameter names defined in JOSE. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/39#issuecomment-184340847 ----==_mimepart_56c21af1ed0bb_79ee3fc7dda5b2b834452e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

If a message is sent from my system to your system and it is not required that you understand the attribute, then it is necessary that you do not define an attribute at the same code point and it is not necessary that you understand this code point.

Information that is company private should be able to remain company private and it should be able to be updated at any time by the company without having to publish new documents.

This is what this allows for and is a totally reasonable issue. This corresponds to using the public header parameter names defined in JOSE.

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

----==_mimepart_56c21af1ed0bb_79ee3fc7dda5b2b834452e-- From nobody Mon Feb 15 10:39:26 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 43B5E1ACCE3 for ; Mon, 15 Feb 2016 10:39:24 -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 7f975VTjvlQo for ; Mon, 15 Feb 2016 10:39:23 -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 07C561ACCDE for ; Mon, 15 Feb 2016 10:39:23 -0800 (PST) Date: Mon, 15 Feb 2016 10:39:22 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455561562; bh=O6/kUt/bk/ILRBHTCtkiYPQR7QwnnhMsfb0O0HiYSKM=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=wbuC7Jsxd9oPqREo0vm+6iPpwyDtw/ffVf7VFxoPjVTQ+mkJiVIgmmYxlIH577fYa GfUKb1KAmPt/TdCLauMdr4e0FGLn56lj4gLQgwvpY6GLTKfo4dKBHchQ2xUhCVZdm0 qub6YVj3NVZ55BTT8LjMZswqhbEQwr0v1h+uGtzQ= From: Mike Jones To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c21b5a45bbf_1c3f3f9f5ba192a011232a7"; 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] Change the definition of label (#56) 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, 15 Feb 2016 18:39:24 -0000 ----==_mimepart_56c21b5a45bbf_1c3f3f9f5ba192a011232a7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I agree with leaving the definition of "label" as-is. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/56#issuecomment-184341604 ----==_mimepart_56c21b5a45bbf_1c3f3f9f5ba192a011232a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

I agree with leaving the definition of "label" as-is.

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

----==_mimepart_56c21b5a45bbf_1c3f3f9f5ba192a011232a7-- From nobody Mon Feb 15 10:41:53 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 CDBC81A90E0 for ; Mon, 15 Feb 2016 10:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 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, 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 LStwNNz4gqCH for ; Mon, 15 Feb 2016 10:41:50 -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 883D21A90DF for ; Mon, 15 Feb 2016 10:41:50 -0800 (PST) Date: Mon, 15 Feb 2016 10:41:49 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455561709; bh=jkpGuSqXz7f+zfFjvcRrOKRqeElpUM+gWPFhuW0qhpo=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=yu4B8boU/wPr76K2XOHDWECqjs+W37djr3CZAwIhwg8uzvN5Ll2ukOgq2nSxs7ybh xMqC6nO4FQo63xJh9Peoa9oh0PXOhC9bbvML+GIUIXQkwuNpN7vbdjdyy5qpeR7zEm GLcNW0bjMaP1DgfOGopSuAoDMTlXx9cwdBwc3CTE= From: Jim Schaad To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c21bedd049a_12ce3f9f5ba192a09766e1"; 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] =?utf-8?b?W2Nvc2UtaXNzdWVzXSBSZXN0b3JlIOKAnHVzZeKAnSBDT1NF?= =?utf-8?q?_key_parameter_description_=28=2323=29?= 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, 15 Feb 2016 18:41:52 -0000 ----==_mimepart_56c21bedd049a_12ce3f9f5ba192a09766e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hit the wrong button --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/23#issuecomment-184342696 ----==_mimepart_56c21bedd049a_12ce3f9f5ba192a09766e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hit the wrong button

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

----==_mimepart_56c21bedd049a_12ce3f9f5ba192a09766e1-- From nobody Mon Feb 15 10:45:15 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 3DFBF1ACDBA for ; Mon, 15 Feb 2016 10:45:07 -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 CK_KelF4Lhes for ; Mon, 15 Feb 2016 10:45:03 -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 5EAB31ACD95 for ; Mon, 15 Feb 2016 10:45:03 -0800 (PST) Date: Mon, 15 Feb 2016 10:45:02 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455561902; bh=nAYtjrOsSkH5i/86IArZUJ9Gh8MQAFN5jqx3JmrUbT8=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Owv17OTL+Z8RGIt1n2yYsw6Cfo7pHwEUBZnEM5JjrULsIfX1SFhUbyrX8EDzqg8aY h/va6Ttu0I1JJ8ZqEtHb0u7YbAu7HSRSAgGapxL7Ily5TDVwe0FrWv5DzrbzmHohC7 eFI38kQFs9JSpioVJNRSALmPUDuhnIZifKjjycCE= From: Mike Jones To: cose-wg/cose-issues Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c21caeaa9dc_59c93f8b100192a0159802"; 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: [COSE] [cose-issues] Appendix A on Making Mandatory Items Optional is both unnecessary and empty (#59) 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, 15 Feb 2016 18:45:07 -0000 ----==_mimepart_56c21caeaa9dc_59c93f8b100192a0159802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Appendix A at https://tools.ietf.org/html/draft-ietf-cose-msg-10#appendix-A contains only this text: Appendix A. Making Mandatory Items Optional A.1. Algorithm Identification A.2. Countersignature Without Headers It's an oxymoron to make mandatory items optional. Therefore, this appendix should be deleted on that basis. It's also devoid of content, and so not useful. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/59 ----==_mimepart_56c21caeaa9dc_59c93f8b100192a0159802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Appendix A at https://tools.ietf.org/html/draft-ietf-cose-msg-10#appendix-A contains only this text:

Appendix A. Making Mandatory Items Optional
A.1. Algorithm Identification
A.2. Countersignature Without Headers

It's an oxymoron to make mandatory items optional. Therefore, this appendix should be deleted on that basis. It's also devoid of content, and so not useful.

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

----==_mimepart_56c21caeaa9dc_59c93f8b100192a0159802-- From nobody Mon Feb 15 11:11: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 289601A9036 for ; Mon, 15 Feb 2016 11:11:38 -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 7gMjEptPJXEI for ; Mon, 15 Feb 2016 11:11:36 -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 BC7B11A9030 for ; Mon, 15 Feb 2016 11:11:36 -0800 (PST) Date: Mon, 15 Feb 2016 11:11:35 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455563495; bh=ts6iWPuiV3NesqgGbzkdi1LrcVueXeNCj+AbDYwipbw=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=08s5jJ+HvJcRQySp9jbO5BWDNf7DHUPm4EWJfSbjiCpaEeXmrblsW7Wk+Mzmjvs/4 MtSron8H+vzNcFCSr2P51x0e6zGLJ2ZBX0MENWkFnjx+ANyXXpSVdTnY9WioLzHzBU +xxkEzHA84g5PSTkRWYC6DC1i071BC7niWeo3tVg= From: Mike Jones To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c222e7cae56_2f2a3ffb3e9732bc1073f"; 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] Remove example features not implemented in the specification (#15) 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, 15 Feb 2016 19:11:38 -0000 ----==_mimepart_56c222e7cae56_2f2a3ffb3e9732bc1073f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Once issue #13 has been addressed, the creation time will not be defined in the document. This issue should be resolved in coordination with #13. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/15#issuecomment-184350426 ----==_mimepart_56c222e7cae56_2f2a3ffb3e9732bc1073f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Once issue #13 has been addressed, the creation time will not be defined in the document. This issue should be resolved in coordination with #13.

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

----==_mimepart_56c222e7cae56_2f2a3ffb3e9732bc1073f-- From nobody Mon Feb 15 11:23: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 C4FA01ACD94 for ; Mon, 15 Feb 2016 11:23:45 -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 VXslB9KwrzLz for ; Mon, 15 Feb 2016 11:23:44 -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 74DAB1AC422 for ; Mon, 15 Feb 2016 11:23:44 -0800 (PST) Date: Mon, 15 Feb 2016 11:23:39 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455564219; bh=S/FkWCMHX2+EN463dkGr3TF3p98+o7REFjKXhXYYsvs=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ar6RNIOr/pX9NnReWQsaUt90MRyI9Ocb20KIiR2F5jpyRn9b8Dhcwh5NFt3sDebIn CCallASHmYY90vv+Zbs7ZyQcS7qLxoJioyjxaPD0trRo7PYogoUfxcPvarTsq8e107 DM7jntdqC+3stGlR7Y+Izb/th32VnGX+ERchIIr8= From: Mike Jones To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c225bb91bc4_e2c3ff95c8f12a05219a"; 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] make "alg" field optional (#51) 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, 15 Feb 2016 19:23:45 -0000 ----==_mimepart_56c225bb91bc4_e2c3ff95c8f12a05219a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I am against making inclusion of the algorithm optional. Among other reasons, doing so would make support for crypto agility more problematic. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/51#issuecomment-184352968 ----==_mimepart_56c225bb91bc4_e2c3ff95c8f12a05219a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

I am against making inclusion of the algorithm optional. Among other reasons, doing so would make support for crypto agility more problematic.

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

----==_mimepart_56c225bb91bc4_e2c3ff95c8f12a05219a-- From nobody Mon Feb 15 11:27: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 EE6A41A90E9 for ; Mon, 15 Feb 2016 11:27:07 -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 MxOg-xegfJ1B for ; Mon, 15 Feb 2016 11:27:06 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext7.iad.github.net [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A15E1A9060 for ; Mon, 15 Feb 2016 11:27:06 -0800 (PST) Date: Mon, 15 Feb 2016 11:27:05 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455564425; bh=YLziQXg85roHYBkovFNu7x5r5uG6NP35kVP8WctNX2E=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=EUoA5b9gNtIIvn4jKmq5MVs09u1sa5x8z9QBsiEUMMBtqvcmvB6kiZ5DwjACHive5 PfRt5dX8RioLMYagKlFnMGP3o+nTshHF2Agw5WItQLRzp2DUoBp4FaDIVp//Z7C1CX JRuELWnzwjKviiZca9rWHw38udHeREWLWoUxlVEU= From: Mike Jones To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c2268951b76_db63ff95c8f12a07261a"; 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] Should we support padding for Enveloped/Encrypted Messages (#53) 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, 15 Feb 2016 19:27:08 -0000 ----==_mimepart_56c2268951b76_db63ff95c8f12a07261a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I agree that no change is needed to add this. Applications can always define their payloads in a way that includes padding, if appropriate. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/53#issuecomment-184354174 ----==_mimepart_56c2268951b76_db63ff95c8f12a07261a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

I agree that no change is needed to add this. Applications can always define their payloads in a way that includes padding, if appropriate.

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

----==_mimepart_56c2268951b76_db63ff95c8f12a07261a-- From nobody Mon Feb 15 11:28:01 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 379B91A9248 for ; Mon, 15 Feb 2016 11:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 WwP1T25LvRDu for ; Mon, 15 Feb 2016 11:27:54 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0137.outbound.protection.outlook.com [207.46.100.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94A61A92EA for ; Mon, 15 Feb 2016 11:27: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=XCD/wYH3/z4rlx8ETAyXN534oMgT7qmhK0TyV9Iu22M=; b=VBYMyW8grL9kolh1A1get0c1OL+mmLeKl4bjvl6uL+eXy/Ma4GsvJpcxoh0WLi1nTsLFBC935lX8VoJTF78RpJmLxg+mcffQkEm+y34nQiUSncZusLBzZB/lw+rA37m+Rw/VB4raxZlZz2SiPqqi9ZqVO1z92NwBGU2B5bfr/zQ= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 15 Feb 2016 19:27:53 +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.0409.017; Mon, 15 Feb 2016 19:27:53 +0000 From: Mike Jones To: "cose@ietf.org" Thread-Topic: More participation needed in discussing COSE open issues Thread-Index: AdFoJvMdJbLuaBkrS4meHt4Y9TPxkQ== Date: Mon, 15 Feb 2016 19:27:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 05a548ee-8d1d-40f2-afc5-08d3363e1957 x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:C3f6nvnT+bz4E/tm289It9gqxI6cJ9apW3rhQnXImE1nILx3voj1zFMZA2jWOSNImfZxvU7tpcugUUIN8vwklO5ng3LEGpLT718x7MvM+o8giDJZsRudWW4JsU3Q7/dYITkZZc/M5OQBqMYYTV5Jww==; 24:oKGfixsMjgR1m70s5Vp4YwRJXoI+NZg2UfH+Gd0NE0Fcc/01dT11FMjr9c37m5CyalT23T+yrgSUqwJ8RrHVwuzDk2ehU4S/7SMQvXGKURU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 08534B37A7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(377454003)(13464003)(53754006)(377424004)(24454002)(99286002)(189998001)(229853001)(92566002)(2351001)(122556002)(5001960100002)(74316001)(107886002)(40100003)(110136002)(450100001)(19580395003)(19580405001)(11100500001)(19300405004)(19617315012)(5008740100001)(5005710100001)(54356999)(10400500002)(10290500002)(16236675004)(50986999)(5004730100002)(5003600100002)(1220700001)(66066001)(586003)(2501003)(33656002)(790700001)(5002640100001)(6116002)(102836003)(3846002)(8990500004)(19625215002)(87936001)(86362001)(2906002)(1096002)(2900100001)(15975445007)(86612001)(77096005)(76576001)(1730700002)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442171296AEEF76892EBD1DF5AC0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2016 19:27:52.7452 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: [COSE] More participation needed in discussing COSE open issues 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, 15 Feb 2016 19:27:59 -0000 --_000_BY2PR03MB442171296AEEF76892EBD1DF5AC0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear COSE working group, As you've seen, there are a few open issues that Jim and I disagree upon. = The two of us could keep going back and forth, but it would probably be mor= e useful if more of you weighed in. I hope that that will happen soon, rat= her than the issues simply being closed without a clear working group posit= ion either way. Those that I know more input would be useful on (in numeri= c order) are: * Move "creation time" value to the payload #13 * Remove example features not implemented in the specification= #15 * Restore "use" COSE key parameter description #23 * Acknowledgements Missing #25 * Require publicly visible stable specifications for IANA registratio= ns #39 I request that the chairs leave those open for working group input, which w= ill hopefully be forthcoming soon. Beyond those that are marked "completed", there's a bunch more at https://g= ithub.com/cose-wg/cose-issues/issues that I'd encourage people to comment o= n, including: * make "alg" field optional #51 I know that there a bunch of different use cases represented in the working= group. It would be really good if people reviewed the resolutions to issu= es before they're closed to make sure that the resolutions work well for yo= ur use cases. Best wishes, -- Mike -----Original Message----- From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin Richer Sent: Monday, February 8, 2016 5:19 AM To: cose@ietf.org Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10= .txt Hello everybody, Please review the list of completed issues in the tracker against the new v= ersion of the document: https://github.com/cose-wg/cose-issues/issues?q=3Dis%3Aissue+is%3Aopen+labe= l%3AComplete We will close all issues marked as "Complete" in one week if there is no co= ntention on the issue. -- Justin, your COSE chair On 2/7/2016 11:29 PM, Jim Schaad wrote: > This version should address all of the open issues in the tracker except = for the optional algorithm pair of items (#51 and #52). > There are two issues that are still unmarked as resolved that are > probably not of great importance > > #54 is only important to the OSCoAP people if they are not planning to > use the CBOR content type option > #53 went out for comment at the start of January and gathered crickets (e= xcept for a comment of that would be nice from Stephen Ferrell). > > Ilari - Once upon a time you made a comment about the context structure a= nd the header fields that can optionally be used for population of it. I h= ave since done a couple of passes trying to do a re-write on it to make thi= ngs clearer. Can you please check if your issue (current CREF2) has been r= esolve? > > Jim > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:= internet-drafts@ietf.org] >> Sent: Sunday, February 07, 2016 8:22 PM >> To: Jim Schaad > >> Subject: New Version Notification for draft-ietf-cose-msg-10.txt >> >> >> A new version of I-D, draft-ietf-cose-msg-10.txt has been >> successfully submitted by Jim Schaad and posted to the IETF repository. >> >> Name: draft-ietf-cose-msg >> Revision: 10 >> Title: CBOR Encoded Message Syntax >> Document date: 2016-02-07 >> Group: cose >> Pages: 105 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-cose-msg= -10.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-10 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-msg-= 10 >> >> Abstract: >> Concise Binary Object Representation (CBOR) is data format designed >> for small code size and small message size. There is a need for the >> ability to have the basic security services defined for this data >> format. This document specifies processing for signatures, message >> authentication codes, and encryption using CBOR. This document also >> specifies a representation for cryptographic keys using CBOR. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.ie= tf.org. >> >> The IETF Secretariat > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose --_000_BY2PR03MB442171296AEEF76892EBD1DF5AC0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear COSE working group,

 

As you've seen, there are a few open issues that = Jim and I disagree upon.  The two of us could keep going back and fort= h, but it would probably be more useful if more of you weighed in.  I = hope that that will happen soon, rather than the issues simply being closed without a clear working group position eith= er way.  Those that I know more input would be useful on (in numeric o= rder) are:

&midd= ot;   = ;    Move = “creation time” value to the payload #13<= /span>

·    &nbs= p;         Remov= e example features not implemented in the specification #15

&midd= ot;   = ;    Resto= re “use” COSE key parameter description #23<= /span>

·    &nbs= p;         Ackno= wledgements Missing #25

&midd= ot;   = ;    Requi= re publicly visible stable specifications for IANA registrations #39

 

I request that the chairs leave those open for wo= rking group input, which will hopefully be forthcoming soon.

 

Beyond those that are marked “completedR= 21;, there’s a bunch more at https://github.co= m/cose-wg/cose-issues/issues that I’d encourage people to comment= on, including:

·       make "a= lg" field optional #51=

 =

I kn= ow that there a bunch of different use cases represented in the working gro= up.  It would be really good if people reviewed the resolutions to iss= ues before they’re closed to make sure that the resolutions work well for your use cases.

 

&nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       Best wishes,

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

 

-----Original Message-----
From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, February 8, 2016 5:19 AM
To: cose@ietf.org
Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10= .txt

 

Hello everybody,

 

Please review the list of completed issues in the= tracker against the new version of the document:

 

https://github.com/cose-wg/cose-issue= s/issues?q=3Dis%3Aissue+is%3Aopen+label%3AComplete<= /o:p>

 

We will close all issues marked as "Complete= " in one week if there is no contention on the issue.

 

  -- Justin, your COSE chair

 

On 2/7/2016 11:29 PM, Jim Schaad wrote:

> This version should address all of the open = issues in the tracker except for the optional algorithm pair of items (#51 = and #52).

> There are two issues that are still  un= marked as resolved that are

> probably not of great importance<= /p>

> 

> #54 is only important to the OSCoAP people i= f they are not planning to

> use the CBOR content type option<= /p>

> #53 went out for comment at the start of Jan= uary and gathered crickets (except for a comment of that would be nice from= Stephen Ferrell).

> 

> Ilari - Once upon a time you made a comment = about the context structure and the header fields that can optionally be us= ed for population of it.  I have since done a couple of passes trying = to do a re-write on it to make things clearer.  Can you please check if your issue (current CREF2) has been resolve?<= /o:p>

> 

> Jim

> 

> 

>> -----Original Message-----

>> From: internet-dr= afts@ietf.org [mailto:internet-drafts@iet= f.org]

>> Sent: Sunday, February 07, 2016 8:22 PM<= o:p>

>> To: Jim Schaad <= ietf@augustcellars.com>

>> Subject: New Version Notification for dr= aft-ietf-cose-msg-10.txt

>> 

>> 

>> A new version of I-D, draft-ietf-cose-ms= g-10.txt has been

>> successfully submitted by Jim Schaad and= posted to the IETF repository.

>> 

>> Name:      = ;            &n= bsp;       draft-ietf-cose-msg

>> Revision:     &= nbsp; 10

>> Title:     &nbs= p;            &= nbsp;          CBOR Encoded Me= ssage Syntax

>> Document date:    &n= bsp;    2016-02-07

>> Group:     &nbs= p;            &= nbsp;      cose

>> Pages:     &nbs= p;            &= nbsp;       105

>> URL:      =       https://www.ietf.org/= internet-drafts/draft-ietf-cose-msg-10.txt

>> Status:     &nb= sp;   https://datatracker.i= etf.org/doc/draft-ietf-cose-msg/

>> Htmlized:     &= nbsp; https://tools.ietf.or= g/html/draft-ietf-cose-msg-10

>> Diff:      = ;     https://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-cose-msg-10

>> 

>> Abstract:

>>     Concise Binary O= bject Representation (CBOR) is data format designed

>>     for small code s= ize and small message size.  There is a need for the

>>     ability to have = the basic security services defined for this data

>>     format.  Th= is document specifies processing for signatures, message

>>     authentication c= odes, and encryption using CBOR.  This document also

>>     specifies a repr= esentation for cryptographic keys using CBOR.

>> 

>> 

>> 

>> 

>> Please note that it may take a couple of= minutes from the time of

>> submission until the htmlized version an= d diff are available at tools.ietf.org.

>> 

>> The IETF Secretariat

> 

> ____________________________________________= ___

> COSE mailing list

> COSE@ietf.org

> https://ww= w.ietf.org/mailman/listinfo/cose

 

_______________________________________________

COSE mailing list

COSE@ietf.org

https://www.iet= f.org/mailman/listinfo/cose

--_000_BY2PR03MB442171296AEEF76892EBD1DF5AC0BY2PR03MB442namprd_-- From nobody Mon Feb 15 11:31:06 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 45A8B1A1BB3 for ; Mon, 15 Feb 2016 11:31:05 -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 SzeR28IclQFB for ; Mon, 15 Feb 2016 11:31:03 -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 C47741A1A31 for ; Mon, 15 Feb 2016 11:31:03 -0800 (PST) Date: Mon, 15 Feb 2016 11:31:03 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455564663; bh=vRTcanSq1Bcf3pCavcr8A6/NOCRJioyiyNwDvt+wZJs=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=GpO7rT/f06dpju7SmLsBjGe9XWyRmfaJmoKspJXSiNrv4FY2MJrYIJhvTmy3xQJLR OruQKE2jU9w4ef2kNviSqFd97KfShPFRhCMANl8Xj6wn2GLF6mcmQ5EgzY3/QjdCde tD33u1OXc389Dh8KF0GFndayL5JpKb7bZIaMoFk4= From: Mike Jones To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c22777d17c_1dde3fbf772bb29c81648"; 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] Tag Request Range for CBOR Tags (#54) 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, 15 Feb 2016 19:31:05 -0000 ----==_mimepart_56c22777d17c_1dde3fbf772bb29c81648 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I strongly believe that we should use one-byte tags. For COSE, size matters. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/54#issuecomment-184355874 ----==_mimepart_56c22777d17c_1dde3fbf772bb29c81648 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

I strongly believe that we should use one-byte tags. For COSE, size matters.

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

----==_mimepart_56c22777d17c_1dde3fbf772bb29c81648-- From nobody Mon Feb 15 11:51:28 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 045B51AC42D for ; Mon, 15 Feb 2016 11:51:23 -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 cLX-MYwJGSPM for ; Mon, 15 Feb 2016 11:51:19 -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 9996B1A003B for ; Mon, 15 Feb 2016 11:51:19 -0800 (PST) Date: Mon, 15 Feb 2016 11:51:18 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455565878; bh=Som4Y0hgsAILBexkwPGoZF5/6mVD+/SWf/8QoJvaNYs=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1DGnNdq0thBOrKpGq73RvOziUTB+gWn056K5zmpcwcCcxFPLnybDnGddH5YzMhbZs 3T+J+GAE5WltjPA5OtCG8FKscThQKfhRySzDbyZZCp6gOWY6nQaABbJaPp2RnKaUc/ nVvXPuARzgyQbk6+4RG7RLaUOkA9IGmMS85JI+P8= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c22c36aebd7_7a693fce680a929c6421cf"; 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] Allocate references to normative and informative (#49) 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, 15 Feb 2016 19:51:23 -0000 ----==_mimepart_56c22c36aebd7_7a693fce680a929c6421cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #49. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/49#event-551140626 ----==_mimepart_56c22c36aebd7_7a693fce680a929c6421cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #49.

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

----==_mimepart_56c22c36aebd7_7a693fce680a929c6421cf-- From nobody Mon Feb 15 11:51:29 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 16DB01A003B for ; Mon, 15 Feb 2016 11:51:26 -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 BryYCtoLsD0F for ; Mon, 15 Feb 2016 11:51:20 -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 B02F61A8AD7 for ; Mon, 15 Feb 2016 11:51:19 -0800 (PST) Date: Mon, 15 Feb 2016 11:51:19 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455565879; bh=85JhkUBVFYmg0HAgCxZOhm/Er7uCjTSQJzK/e+Mz09I=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1uefjjt8xd0UROkuk/LTMNYsHnnE3k6ks01vmMkvN/AqaejX8j3kXZpJApTZZi2oR CeiL7aYxwveOK7rLFtQyFgj7m7UzVAQPVSeew1LJd4sgEkNgcKiqtc1JYiLDgGRyrl ky1O0OV9JaMKBWOJ7uDK5dWNLWbJ8/j/XWNZczGE= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c22c377869_27b33fa1446f52a0635640"; 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] Change the definition of label (#56) 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, 15 Feb 2016 19:51:26 -0000 ----==_mimepart_56c22c377869_27b33fa1446f52a0635640 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #56. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/56#event-551140629 ----==_mimepart_56c22c377869_27b33fa1446f52a0635640 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #56.

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

----==_mimepart_56c22c377869_27b33fa1446f52a0635640-- From nobody Mon Feb 15 11:51: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 EFFEF1A003B for ; Mon, 15 Feb 2016 11:51:26 -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 WQ-pCyy48Hvr for ; Mon, 15 Feb 2016 11:51:23 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext7.iad.github.net [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06331A923D for ; Mon, 15 Feb 2016 11:51:19 -0800 (PST) Date: Mon, 15 Feb 2016 11:51:18 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455565878; bh=uwLUGlqXV7spI9JFjD+7ncIFTW/3dx2iwDYDuQCqHMk=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=R6K7L2L9M9Qw7u+ZZJEgWDQG3plkTVccShWHvCKdl/DXzXESPLGHCGcRD36HEQece 2AX9ByQFu6+FOEuB7QwxUw7Ccfmx4ppr40TZttjXUcVcbfpnA3TqmfJNP3Xop/jo8I RTzo6jX8nLhNt6jLKTAkxd0iwmflNp2cY+zuLK4c= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c22c36a4671_18633f9e85d532bc772363"; 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] Order appendices by importance (#40) 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, 15 Feb 2016 19:51:27 -0000 ----==_mimepart_56c22c36a4671_18633f9e85d532bc772363 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #40. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/40#event-551140624 ----==_mimepart_56c22c36a4671_18633f9e85d532bc772363 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #40.

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

----==_mimepart_56c22c36a4671_18633f9e85d532bc772363-- From nobody Mon Feb 15 11:51:32 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 5AD3E1A9090 for ; Mon, 15 Feb 2016 11:51:27 -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 iYlrzmkCLeRZ for ; Mon, 15 Feb 2016 11:51:26 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext7.iad.github.net [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45AD1A009C for ; Mon, 15 Feb 2016 11:51:19 -0800 (PST) Date: Mon, 15 Feb 2016 11:51:19 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455565879; bh=mflnxSE8VyWfokcpMaoJ689rAvNqi2G/Hu8k0Bg8hVc=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=DpmGtbbjmtYaKepmj06otJNzhkfJCp6LOuFbuERwSbi5cAOWZgEEkVqiIyI/Q/nRM 6K5h2ST2N8Iy8EFLYA1ESjgnpfHMVyW3dVfw528s2CDI2BVBf+Wk3bLrsiDXfOo5fX pV5P6qOTBlo5EW3GRbRy4GEib/SeRj292GrZ3zoU= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c22c372cba_7aa53fce680a929c6855b1"; 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] Define a curve registry. (#55) 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, 15 Feb 2016 19:51:27 -0000 ----==_mimepart_56c22c372cba_7aa53fce680a929c6855b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #55. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/55#event-551140627 ----==_mimepart_56c22c372cba_7aa53fce680a929c6855b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #55.

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

----==_mimepart_56c22c372cba_7aa53fce680a929c6855b1-- From nobody Mon Feb 15 12:14: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 306571AD0C8 for ; Mon, 15 Feb 2016 12:14:16 -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 xrVanf6_PCPe for ; Mon, 15 Feb 2016 12:14:14 -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 B397D1AD0C5 for ; Mon, 15 Feb 2016 12:14:14 -0800 (PST) Date: Mon, 15 Feb 2016 12:14:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455567253; bh=KvN6CvxiPRwTuDFxXS/6Qc0WvphxnSyptC1gLQOAyX0=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=LaKwFuhSPSj3/S5rsM5qWuKgfMUNdhyjTwRFeLv2iVOE2CFHKk18Y2TFYguDyk4B2 +DAlS5C82BlMRhjqLREjMGHs2zuoAfpU2kzoVWJIAikyrJH4n0Mk1G43VoUcvJg3y+ obOS6Vr5GbRXTsD5zg8CsUdEYTrwhWFerb3ckTgQ= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c23195ce492_59b3fdba0ad32a012510"; 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?b?W2Nvc2UtaXNzdWVzXSBSZXN0b3JlIOKAnHVzZeKAnSBDT1NF?= =?utf-8?q?_key_parameter_description_=28=2323=29?= 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, 15 Feb 2016 20:14:16 -0000 ----==_mimepart_56c23195ce492_59b3fdba0ad32a012510 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #23. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/23#event-551161784 ----==_mimepart_56c23195ce492_59b3fdba0ad32a012510 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #23.

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

----==_mimepart_56c23195ce492_59b3fdba0ad32a012510-- From nobody Mon Feb 15 12:16:41 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 1FF2F1ACE12 for ; Mon, 15 Feb 2016 12:16:40 -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 TZ2igYo57Lij for ; Mon, 15 Feb 2016 12:16:38 -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 C76F21A90DC for ; Mon, 15 Feb 2016 12:16:38 -0800 (PST) Date: Mon, 15 Feb 2016 12:16:38 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455567398; bh=ebMSAy2dPHyWAHAtTN9/RGOx/yZd6EjZB2TLwtsXchQ=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=U1fUiuF81tlUZr3nxbwn65qo8Xjnw90yIUTFGzVce2tsWNNuDWc7Bf9kuwVx/IwXz S9+MVZlQilZxgFyeRBv+1tP9iiaL6MJ+BNDAtb9eCb4+dcaxBpqwtqBGr83PoqDeMh JDFsD05djzRR7qGmAooc2j45SCm9XaWJ/+qlfe6k= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c2322616934_3e223fbcdae6b2bc124779"; 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] Acknowledgements Missing (#25) 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, 15 Feb 2016 20:16:40 -0000 ----==_mimepart_56c2322616934_3e223fbcdae6b2bc124779 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #25. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/25#event-551164286 ----==_mimepart_56c2322616934_3e223fbcdae6b2bc124779 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #25.

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

----==_mimepart_56c2322616934_3e223fbcdae6b2bc124779-- From nobody Mon Feb 15 12:16:53 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 440331ACEE5 for ; Mon, 15 Feb 2016 12:16:50 -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 Kfws4_69t65u for ; Mon, 15 Feb 2016 12:16:47 -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 AC9CE1AD21C for ; Mon, 15 Feb 2016 12:16:47 -0800 (PST) Date: Mon, 15 Feb 2016 12:16:38 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455567398; bh=lev6uGQig1+fQu6YL0NvBhrOj4dQCGhmoQ6ZnuvW9+o=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=X4m4D0RZxAq5vexXifUh4illPFi/MJ8QPE9bOITTjGbjvDqXx2ZezaPq8CgmKD7VZ j3o3pvhG9mjPptS6AG/OH5hEysYE/06yxRvLbh/WcAgY8DyUieJimyw3MQexi1Ab3w Us/ERGD1CAN99M8EG2WuqtjOisneivHDq4j90uMs= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c2322611c18_f283feff71e92a0100177"; 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] Acknowledgements Missing (#25) 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, 15 Feb 2016 20:16:50 -0000 ----==_mimepart_56c2322611c18_f283feff71e92a0100177 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit The section has been created, and it's up to the editor how to list the acknowledgements as they see fit (within reason). That said, during WGLC we will work with the editor to make sure the appropriate acknowledgement is given in the final document. Closing this issue. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/25#issuecomment-184370266 ----==_mimepart_56c2322611c18_f283feff71e92a0100177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

The section has been created, and it's up to the editor how to list the acknowledgements as they see fit (within reason). That said, during WGLC we will work with the editor to make sure the appropriate acknowledgement is given in the final document.

Closing this issue.

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

----==_mimepart_56c2322611c18_f283feff71e92a0100177-- From nobody Tue Feb 16 01:34: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 26F9E1B2D07 for ; Tue, 16 Feb 2016 01:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, 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 6ucStq9kRddn for ; Tue, 16 Feb 2016 01:34:32 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92EB1B2CFF for ; Tue, 16 Feb 2016 01:34:31 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id x1so13187276lbj.3 for ; Tue, 16 Feb 2016 01:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=jnmPK54s0psKHNrkT7gQj7FzBPjFZ6b1AqkoBcc7Kz0=; b=iETZKSGssfYIgB6fP2EzpTi6XOId3T+/90F9Z5SFU12fnl0RLe4e6qoN9njdDK+oLo Tx9JqfpBrwVVmJ7Muz7AhD10eqQXFCCUb/W3iE1ftiGmxKDJzix4eTaaTMBMahNSGvYP kGj3M8NLDrMiix+5RgXu/8yQLwyTeVR+tbOcKfI1k1srfrH+kzBrUt/FMyflDpf62rrV 0Z9lf/5FzWoXzvNQGMuOuTSq3XHVrzto18EmnQCB/lfq8b+2zEfPuvBsYIZ/YdncZRm7 tmZjB/xK5dzDhvpcXCVxA4C9HZzrd95iR6hXNMV/uCridFVDVfrLCgMBxfEqi4Svci9G emkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=jnmPK54s0psKHNrkT7gQj7FzBPjFZ6b1AqkoBcc7Kz0=; b=CNu+gFOypoPEDky0geUIXd+HFC+ujij2pNHlApWLrgg7kLo4Y2jX231w48uRvX+l5W ByiTqZyhzO2DjDSejj9Y9KjNoUiDkPIDHp+VpHkp07MJeHsUl5fW46tLTtl+ecI+lCTh jjux1fg2N9Xu0WhQDAkSv6by0CPXJG2urJKU20TH/kaztRFFtwl35wvGgwVMqWjC2YH6 5CiT4LveEvAIF4FoWEXm4KgM04CAors4/nd1dGpjQPpMvGUZATkoawXd2RvRfGDL6f9d szWAt1UnCme374lCxDpgaaDpZI1024fKUQjGEjS/GsodUZMMqikcvrwZEusQaTlvN/F5 EdGA== X-Gm-Message-State: AG10YOQoYsIzmA88xI7PuKWOxGRAIhcxIq9pkFVpgL2fNcGvGZOkDvmfSv5IV0y5//QfDc1T X-Received: by 10.112.125.9 with SMTP id mm9mr7534131lbb.113.1455615270105; Tue, 16 Feb 2016 01:34:30 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id r191sm4233039lfe.28.2016.02.16.01.34.29 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Feb 2016 01:34:29 -0800 (PST) To: cose@ietf.org References: <00b401d14a72$eccb5210$c661f630$@augustcellars.com> <040d01d14ccd$30bb4140$9231c3c0$@augustcellars.com> <052701d14d68$dc395f20$94ac1d60$@augustcellars.com> From: Ludwig Seitz Message-ID: <56C2ED17.2000102@sics.se> Date: Tue, 16 Feb 2016 10:34:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040308010508020203000003" Archived-At: 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, 16 Feb 2016 09:34:34 -0000 This is a cryptographically signed message in MIME format. --------------ms040308010508020203000003 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 02/15/2016 07:08 PM, Mike Jones wrote: > Yes, I=92ll grant you that the content type value belongs because it=92= s > generally useful and metadata **about** the payload. Whereas, the > creation time field is **part** of the payload. It also duplicates the= > CWT issued-at field. It still needs to be removed to address this > issue. Marking this one as =93complete=94 is an incorrect categorizati= on of > the issue. > > -- Mike I find this distinction artificial. Creation time can just as well be=20 seen as metadata about the payload as content type. Furthermore, as you said, the 'issued-at' field is part of CWT (as in=20 Cose-Oauth tokens). We plan to use Cose for a number of different=20 payloads, where not all of those are CWTs. Providing a standardized way to indicate the creation time of a Cose=20 object (e.g. to allow for replay protection, expiration, and to protect=20 against reordering) seems like a reasonable security objective to me. If we instead push this down to the applications, we risk getting a=20 number of different incompatible specifications. Regards, Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70 349 9251 http://www.sics.se --------------ms040308010508020203000003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMTYwOTM0MTVaMC8GCSqGSIb3DQEJBDEiBCDz/FUK83jfRos+ MFyQy1c1PS4WCBMnC+ioB0xX0feZXjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQAjzlYGLT3L0DBcfb8IPmYVRvM2 xfkZThF/mIDq8ECdUGO6HymV7Jg29BuC7tvOd0PRA+4peNKFGOlODB2lyD86gxpC6d28oW6T L+IbUrUzylm9Ut7L4SkCId+NC8roD5GDhygv21r4MTij1cWFqN+txwUaaKy6GPWA04XGX6sl fP0TTThIXftGTC4P0yvnoHI5F8Y5CMaOCj+9SPbN7rVivFDPJ5xUsa5vC++rteqlGVvSAEso 8WWeQ+6uXXTSFP94poYWoNQ1A6PfEowxyNyxdyhaQYuexfAO0NQoh0oEY8a4dcWP20zVfQma jURHE05jInkcmq8gIf8Me7z3Y+pBAAAAAAAA --------------ms040308010508020203000003-- From nobody Tue Feb 16 01:39: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 364A81B2CA1 for ; Tue, 16 Feb 2016 01:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 K7B8mdsM3it0 for ; Tue, 16 Feb 2016 01:39:23 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E87B1B2C96 for ; Tue, 16 Feb 2016 01:39:23 -0800 (PST) Received: by mail-lb0-x233.google.com with SMTP id x1so13257767lbj.3 for ; Tue, 16 Feb 2016 01:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=UIUJ4pEgnRTgtm25p7U/+fJm41BsTLVcLfHmP0IpxkA=; b=dnavV2rl9PGMfjbr9At4GCjtolpuNHX+pEIY0SqSC2+GXZkSOyTvOH1VnEOGfUsYK2 60yHZVJfDqXks81faJXqencaqrm6nWGEWeOivYy+saYGnyOfjWTTPm2J4G1XHeaZISx2 SMlCS6ZVm5t3BtIVivtRTzbtj4u7s/Urz2iwqyghZ8L2ZXhqK3nrrjyBH2fQqM9EZ/5I Qu/mKMAxOY6/JrJnU83l+EMJTI6YotWrXncEapn2kGBGk+Y9FswY4QuqfJ86TRhL6K53 ztVjFeedFf5wgLkuBmQGP0pwqFIBOK71SIbRx2ORMWO2vwzNU2WqL98eJtmiWTbkUS42 +4Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=UIUJ4pEgnRTgtm25p7U/+fJm41BsTLVcLfHmP0IpxkA=; b=RC/8nH/XFRrr/VTk7u+qsp7TNi5w1t0zx9y52eu+6iNE/yx+yMxOsnQheINWavs8BL WDuQZa114U2AAGBmhjuyK5oervEhBs8pLGzAUezdxVynmNH2phWawbJTqSLF4uvwqgDN UvhTSNjPk+BG56uiPcftxxJVPk01YJ1xY2Q+elEf4koob4N2lY3Vrg4LDSb/2MtEDUIV 8ze4RPZYLwGzPsYRuYyaNrPD8YZwcY/DJ4+9pNVzw+u/ym6qm0bGo8UASqQagcT6tOcc E8ROYYieZGIYc8anzXZXSYZeFYLtkyAKJ/WcT6a//nWOqHxJD5t1wOILu9kmTJvlbYIl r/RA== X-Gm-Message-State: AG10YOSqBppN1jN7S0TTd/YWzAsaBXrUyk7FXvkcBrg6TvoFq4ERTUVtJfzlEkMrkRLDIJ+S X-Received: by 10.112.136.103 with SMTP id pz7mr478413lbb.98.1455615561564; Tue, 16 Feb 2016 01:39:21 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id dt9sm3993783lbc.47.2016.02.16.01.39.20 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Feb 2016 01:39:21 -0800 (PST) To: cose@ietf.org References: From: Ludwig Seitz Message-ID: <56C2EE48.9080601@sics.se> Date: Tue, 16 Feb 2016 10:39:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000307020703040708090101" Archived-At: Subject: Re: [COSE] [cose-issues] Acknowledgements Missing (#25) 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, 16 Feb 2016 09:39:26 -0000 This is a cryptographically signed message in MIME format. --------------ms000307020703040708090101 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 02/15/2016 07:27 PM, Mike Jones wrote: > While an Acknowledgements section has been added, all it says is "This > document is a product of the COSE working group of the IETF." This does= > not satisfy the intent of having an Acknowledgments > section, which is to acknowledge by name those who have made significan= t > contributions to the specification. This is not only a standard practic= e > and a common courtesy - it's the right thing to do. > > Until this is done, it is incorrect to categorize this issue as "comple= te". > +1 There is no public and persistent registry of who is part of "the COSE=20 working group". Therefore it is not possible to identify the persons=20 being acknowledged. This might actually be relevant for those who have=20 to justify the time spend contributing towards whoever pays them for it. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70 349 9251 http://www.sics.se --------------ms000307020703040708090101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMTYwOTM5MjBaMC8GCSqGSIb3DQEJBDEiBCCdP9PoklSu7kMe Tx+10f6b5hm9RCe3gTOmio+HibO2/jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQAd92NeTs36ReO/85cjCQdVtiwd Af524SQj3ARvv+4UqR1IvpYS47kRITqkOGAQGa6rbNaZkwR8K0i8+2WKE1NTv199pyVMGbLP 1u6binvPIT2DHz2VDHK7NyJHl0vuBFwHYxkep+gF+5KpkA2iRD7Og0VOt5X3XeP16j3W/8dl paR1MXd3vWCALpI6B+HDBVommdkHnDXcAQCpDgLhWBCHb8SRLwCfztCrtGMjHG1W0puCMP/b YmagZQOAlUReFxMfVeb3hM5GxxVFrIVcbY+foq8EhYMx5p/FrlgTkpDEW5933oD6skLtrlNJ MUl2jV5216k0IkWMfE8+tdLbws34AAAAAAAA --------------ms000307020703040708090101-- From nobody Tue Feb 16 01:54: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 4E79A1B2DF9 for ; Tue, 16 Feb 2016 01:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 k69X6Rn0N1r3 for ; Tue, 16 Feb 2016 01:54:39 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 37F301B2DF5 for ; Tue, 16 Feb 2016 01:54:39 -0800 (PST) Received: by mail-lb0-x22b.google.com with SMTP id x4so92562897lbm.0 for ; Tue, 16 Feb 2016 01:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=Evh5iAfta2EKsKS+VJONHzOWNTXuT00g0aJltu9q5zA=; b=OoQiaGtP8+beAPgKWDFvalR9IN3Xcp4V1JjXdsk20w1wJF+2fCn2l+p4mC+DCB6gy5 xRLkrbffiqFsbvusK0cLloV1JAAghltrNArLDVWMcJPQPh24sNb2iUcCShC1VpDe779p dqE/fhKB6eZq7ySn8pRUZGUW6gKbNWJrCEc7gzJFEKr+wgpn3Ll4+kbM+vVKnDxiF242 nGgL81OwbfXc5KNIGu+yHbM2qyqDWboF7LF+uR08WzwVwvU3Q271cKomf4YANKG2hEYA 3RTUIv0e8fNUpQH24jeSYCZ2g2g19MWp92QW2Ns4i3jAR9I1xLe4a6SDNg7gm0ojvhKk 0QRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=Evh5iAfta2EKsKS+VJONHzOWNTXuT00g0aJltu9q5zA=; b=Z0n1n5brP9QM6WSsjUQQKqrIzVoHFTpJFzfTqXVn2HSbb30tqYrcuA7T9K++Ay4b+w kNJKQ2LRjhQ8Rm+cxPFAaLBUq5KS95DlpDFJRXuAhGDroKT1UKxkTtQSa/CW90HlPyID yOYztl2blUaMmKV7urMbsFZEIJ5iNe6Wxdco7OWczp91tBFz2BNb8YbQr41uFr5SdwfD 8K9/2ZPDZdNE1udcKZ5TJGy+Jf9I6edBPZcnzijQiQAvdsoZ+O5Xms4CuQyAkHYc/XdX S+R5ztPHt3taq5H0R4H0wLJmqiRBEkKUDV6AwW3sUCdJJN+iNS7zqOhnxu4H61lB4QQw 2A6A== X-Gm-Message-State: AG10YOS4Xmx1yYdnCth6Ph1F202nvHo584V9XNd3G4n6x0rPb6UeO5qrX1tmF4zVfiM64/+k X-Received: by 10.112.38.104 with SMTP id f8mr8966568lbk.115.1455616477316; Tue, 16 Feb 2016 01:54:37 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id rp10sm4190385lbb.13.2016.02.16.01.54.36 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Feb 2016 01:54:36 -0800 (PST) To: cose@ietf.org References: From: Ludwig Seitz Message-ID: <56C2F1DC.5090505@sics.se> Date: Tue, 16 Feb 2016 10:54:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010708000200040700040105" Archived-At: Subject: Re: [COSE] [cose-issues] make "alg" field optional (#51) 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, 16 Feb 2016 09:54:41 -0000 This is a cryptographically signed message in MIME format. --------------ms010708000200040700040105 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 02/15/2016 08:23 PM, Mike Jones wrote: > I am against making inclusion of the algorithm optional. Among other > reasons, doing so would make support for crypto agility more problemati= c. > While I can sympathize with your position in general, in the constrained = cases (and that's what COSE aims for) crypto agility is not really=20 feasible, since you would typically only have one algorithm of every=20 type needed implemented on a device. Replacing a crypto algorithm would then typically require a firmware=20 update, removing the old algorithm in the process (to save space). Therefore I would argue that in those cases it is acceptable to assume=20 that the algorithms are known by both communicating parties and that=20 they don't need to be specified explicitly. In the rare cases where a device would not know the algorithms used by=20 its communication partner, external discovery mechanisms can provide=20 this information, thus offloading the constrained devices from=20 performing this task. Regards, Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70 349 9251 http://www.sics.se --------------ms010708000200040700040105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMTYwOTU0MzZaMC8GCSqGSIb3DQEJBDEiBCDSbjskC1XL0nuv uwye8n9ZFdXB3RqtCi6iuSDkhq5nIzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQBG5FWhLKiDTmgxMkHJxec7z5V1 q4JUO9l4F+OCLNqCESgHkkHIJFc+ZBXM52cFEx/lMCsCHANmsXoUgg6deAaEPLCmuS3npxsi JTgq3loscVg4gAgUsFaS3/drhztqlgPhdMPcanRHddfQNZ3ig8wEND7Vv9uDTjb+N3EFC+r5 Um2H32HUbt9OkVYAkL3B5WxQdWxUh1iMj5fYFXIRuvWYkmCwQrDPj0crxhf+oww3Fbz4iFOV bj2nGZ2i3MFw/wo8L8E+QdTu+qc1VdlYpT4rspuF0898391USrdYu3n2gH9CkZ/oCR3l5pSQ I3UW5LEuWcGacb/imWpi3agSFYYoAAAAAAAA --------------ms010708000200040700040105-- From nobody Wed Feb 17 05:47: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 826EB1AC3C2 for ; Wed, 17 Feb 2016 05:47:41 -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 pDwmeRoDfm2j for ; Wed, 17 Feb 2016 05:47:40 -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 060AA1A90A9 for ; Wed, 17 Feb 2016 05:47:40 -0800 (PST) Date: Wed, 17 Feb 2016 05:47:38 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455716859; bh=raQ23Nfxch7T8LA7YoXjgidyf9OS+RRugpRo7fc6S8E=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=n8m4ELVGjFOgtOfc1hAj/2T1lR6sH8FWDlUDiSj26ELSuObPW/y5GGfS06tC6g5Wa O5dfGOMKJ2tRxRksKEBVxEJrfgiGfOCCtIbzLvam8PoEMGF8EpHou+CT4Ul+RaIjMX LzH0exaZBI5aFUd6k2bvrF5H8dmJ/gYeIZxpvJJ8= From: fpalombini To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c479faf1a6f_55183f8a5e6492b833285"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: fpalombini X-GitHub-Recipient: cose-ietf X-GitHub-Reason: comment X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Cc: cose-ietf Subject: Re: [COSE] [cose-issues] Tag Request Range for CBOR Tags (#54) 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: Wed, 17 Feb 2016 13:47:41 -0000 ----==_mimepart_56c479faf1a6f_55183f8a5e6492b833285 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I think it makes sense to request one-byte tags only for the structures that aim at minimizing the size to the smallest size possible, namely COSE_Sign1, COSE_Mac0 and COSE_Encrypted. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/54#issuecomment-185210595 ----==_mimepart_56c479faf1a6f_55183f8a5e6492b833285 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

I think it makes sense to request one-byte tags only for the structures that aim at minimizing the size to the smallest size possible, namely COSE_Sign1, COSE_Mac0 and COSE_Encrypted.

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

----==_mimepart_56c479faf1a6f_55183f8a5e6492b833285-- From nobody Wed Feb 17 06:08:48 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 64EEA1B3AA9 for ; Wed, 17 Feb 2016 06:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.783 X-Spam-Level: X-Spam-Status: No, score=-4.783 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, HTTP_ESCAPED_HOST=1.125, 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 L2MYJ7jtA_uC for ; Wed, 17 Feb 2016 06:08:45 -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 CA6811B3AA7 for ; Wed, 17 Feb 2016 06:08:45 -0800 (PST) Date: Wed, 17 Feb 2016 06:08:37 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1455718117; bh=O9txF5OwySO5qzV1X7XFSaYk8XvZHCMyrajlafUKH8Y=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=vQ6zJVrd1eja8/ieqDmFepTkGjVFgv5VhiYCCD74gEWV1qHoinDrT3EWtEtkZKh/h ywF0rZjTfZBLoQczpLuwjCXudta4T2wjWnELeiSh45ST1DLlGfafb/6o7f9VnBsgnF 4epB6V6FeIDwFmkf24P09bMkxWUBIeuBhRRHxaI8= From: fpalombini To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56c47ee5a613c_75e13fc2f28472a07431d"; 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: 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: Wed, 17 Feb 2016 14:08:47 -0000 ----==_mimepart_56c47ee5a613c_75e13fc2f28472a07431d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Mike, the goal behind this is again to reduce the size of the COSE message: instead of using a COSE_Signature structure (which itself contains headers and bstr signature value), we would like to use the simple bstr signature value directly. This would reduce the size of 3B: 1 for the array, 1 for the unprotected header and 1 for the protected header. (the discussion about this in the mailing list is [here]([COSE] Issue - add the value type 'bstr' to counter signature)). --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/52#issuecomment-185221066 ----==_mimepart_56c47ee5a613c_75e13fc2f28472a07431d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi Mike, the goal behind this is again to reduce the size of the COSE message: instead of using a COSE_Signature structure (which itself contains headers and bstr signature value), we would like to use the simple bstr signature value directly. This would reduce the size of 3B: 1 for the array, 1 for the unprotected header and 1 for the protected header.

(the discussion about this in the mailing list is here).

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

----==_mimepart_56c47ee5a613c_75e13fc2f28472a07431d-- From nobody Wed Feb 17 06:26: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 2961B1B2A05 for ; Wed, 17 Feb 2016 06:26:45 -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 Z7VTHuSUjWJF for ; Wed, 17 Feb 2016 06:26:43 -0800 (PST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B701ACD84 for ; Wed, 17 Feb 2016 06:26:43 -0800 (PST) Received: from mfilter38-d.gandi.net (mfilter38-d.gandi.net [217.70.178.169]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id A354E41C086; Wed, 17 Feb 2016 15:26:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter38-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter38-d.gandi.net (mfilter38-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 58_Rf6hLLb7h; Wed, 17 Feb 2016 15:26:40 +0100 (CET) X-Originating-IP: 134.102.93.67 Received: from eduroam-pool11-324.wlan.uni-bremen.de (eduroam-pool11-324.wlan.uni-bremen.de [134.102.93.67]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 82FD341C0AC; Wed, 17 Feb 2016 15:26:39 +0100 (CET) Message-ID: <56C4831D.4030409@tzi.org> Date: Wed, 17 Feb 2016 15:26:37 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: cose-wg/cose-issues References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: cose-wg/cose-issues , cose-ietf Subject: Re: [COSE] [cose-issues] Tag Request Range for CBOR Tags (#54) 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: Wed, 17 Feb 2016 14:26:45 -0000 fpalombini wrote: > I think it makes sense to request one-byte tags only for the structures > that aim at minimizing the size to the smallest size possible, namely > COSE_Sign1, COSE_Mac0 and COSE_Encrypted. +1 Grüße, Carsten From nobody Wed Feb 17 18:39:41 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 5F7551B3119; Wed, 17 Feb 2016 18:39:39 -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 u8jxyS1Sq8B7; Wed, 17 Feb 2016 18:39:38 -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 18E7D1B3116; Wed, 17 Feb 2016 18:39:37 -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 989672CA32; Wed, 17 Feb 2016 18:39:36 -0800 (PST) From: "Jim Schaad" To: Date: Wed, 17 Feb 2016 18:37:03 -0800 Message-ID: <00dd01d169f5$40bb3650$c231a2f0$@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: AdFp9TVtcKkh1tfxTVyTEMRLKIe6EQ== Archived-At: Cc: cose@ietf.org Subject: [COSE] Duplicate Bug Closure Request 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, 18 Feb 2016 02:39:39 -0000 I request that the chairs close issue #60 as a duplicate of issue #25. Jim From nobody Wed Feb 17 19:15: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 195E01B33D5; Wed, 17 Feb 2016 19:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 4dTaWM0kcpHW; Wed, 17 Feb 2016 19:15:27 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1247A1B33D1; Wed, 17 Feb 2016 19:15:26 -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=m1KYuBPQ7eqSrOfa3U+sdOcnvdsVTR4Z/WKeZtgQd7s=; b=PXdFf3+qTI4EDeDGCP8NI44pCDFs2jAoDsQ3KHvZRdyAXeGCtgMd+oD8MjLFGTVJCH+/bxCU0jfT9F2+1f3PbVQdrHvhL5h6jGtcqDsXJHmr8xvDFXm26kuMGvrDXhfMQ0eyiRKqBDzKlH5OnSOMzhwcFFHJ7FqQj1rXBYX3KR4= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 18 Feb 2016 03:15:05 +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.0409.017; Thu, 18 Feb 2016 03:15:05 +0000 From: Mike Jones To: Jim Schaad , "cose-chairs@ietf.org" Thread-Topic: [COSE] Duplicate Bug Closure Request Thread-Index: AdFp9TVtcKkh1tfxTVyTEMRLKIe6EQABAj+Q Date: Thu, 18 Feb 2016 03:15:05 +0000 Message-ID: References: <00dd01d169f5$40bb3650$c231a2f0$@augustcellars.com> In-Reply-To: <00dd01d169f5$40bb3650$c231a2f0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: d1ef11f6-f3f2-475d-cd9e-08d33811b2c2 x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:KE7Hz0Fsoo8+lO3DV80wamB6KKvmCOsIo0ZJ3BQpwArpLtCLcjHGXnyKR+WKXQvsDxKhf83ifDNvISxycHHjDQJdpRnXq7sPJvQUnAl3wFOmV7+0wQKlFh2gvubGROaD189txD6yapxWeg0oYXHqig==; 24:x9WkoAsUBGy0fKniXn2q2xCner8iaxx0YoOe5Pt/hgSy2WajpANzS6Xv4UnglTqzuf9dNk0TaZtophTHcGyDJJfshu8zkyINIFQUTp3Izxk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(377454003)(13464003)(586003)(10290500002)(2501003)(66066001)(102836003)(6116002)(3846002)(790700001)(16236675004)(5002640100001)(5003600100002)(10400500002)(76176999)(10090500001)(54356999)(33656002)(5004730100002)(5005710100001)(1220700001)(3660700001)(87936001)(50986999)(15975445007)(76576001)(8990500004)(3280700002)(2906002)(19625215002)(86362001)(4326007)(77096005)(86612001)(2900100001)(2950100001)(1096002)(74316001)(189998001)(92566002)(11100500001)(5001770100001)(122556002)(40100003)(5001960100002)(5008740100001)(19617315012)(19580395003)(19580405001)(19300405004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4426D09D63AA1A10EEDF969F5AF0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 03:15:05.1582 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] Duplicate Bug Closure Request 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, 18 Feb 2016 03:15:31 -0000 --_000_BY2PR03MB4426D09D63AA1A10EEDF969F5AF0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable #60 requests that individ= uals be acknowledged for their contributions. This is common professional = courtesy. #25 asked for = an acknowledgements section, which draft -10 vacuously satisfied, without s= atisfying the clear intent of the issue. #60 is more specific, since the "resolution" to #25 didn't resolve the issue. Ludwig Seitz also supported having meaningful acknowledgements in https://m= ailarchive.ietf.org/arch/msg/cose/upMMmWl7by6A7H9vAVsCTa6ml8Y. I don't care whether we use #25 or #60 to track the issue, but one of them = needs to remain open until meaningful acknowledgements are in place. Thanks, -- Mike -----Original Message----- From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, February 17, 2016 6:37 PM To: cose-chairs@ietf.org Cc: cose@ietf.org Subject: [COSE] Duplicate Bug Closure Request I request that the chairs close issue #60 as a duplicate of issue #25. Jim _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose --_000_BY2PR03MB4426D09D63AA1A10EEDF969F5AF0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

#60 requests that individuals be acknowledged for their con= tributions.  This is common professional courtesy.  #25 asked = for an acknowledgements section, which draft -10 vacuously satisfied, witho= ut satisfying the clear intent of the issue.  #60 is mor= e specific, since the "resolution" to #25 didn't= resolve the issue.

 

Ludwig Seitz also supported having meaningful ack= nowledgements in https://mailarchive.ietf.org/arch/msg/cose/upMMmWl7by6A7H9vAVsCTa6ml8Y.=

 

I don’t care whether we use #25 or #60 to t= rack the issue, but one of them needs to remain open until meaningful ackno= wledgements are in place.

 

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

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            -- Mik= e

 =

-----Original Message-----
From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 17, 2016 6:37 PM
To: cose-chairs@ietf.org
Cc: cose@ietf.org
Subject: [COSE] Duplicate Bug Closure Request

 

I request that the chairs close issue #60 as a du= plicate of issue #25.

 

Jim

 

 

_______________________________________________

COSE mailing list

COSE@ietf.org

https://www.iet= f.org/mailman/listinfo/cose

--_000_BY2PR03MB4426D09D63AA1A10EEDF969F5AF0BY2PR03MB442namprd_-- From nobody Wed Feb 17 21:09:28 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 D4F2B1B35A2 for ; Wed, 17 Feb 2016 21:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-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 TcfVk69asv7O for ; Wed, 17 Feb 2016 21:09:25 -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 B3C431B35A1 for ; Wed, 17 Feb 2016 21:09:25 -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 256542CA32 for ; Wed, 17 Feb 2016 21:09:25 -0800 (PST) From: "Jim Schaad" To: Date: Wed, 17 Feb 2016 21:06:52 -0800 Message-ID: <00f401d16a0a$2e20be10$8a623a30$@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: AdFqCdpU8N34fsg3SYa1CHuNHqIVHw== Archived-At: Subject: [COSE] JAVA implementation of COSE 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, 18 Feb 2016 05:09:27 -0000 As an FYI for the group. I was requested to make some changes to the C version to get a constrained crypto and also to create a JAVA implementation of the C# code. I am currently in the midst of doing the later and will do the former in the next couple of weeks. I do not have a good idea of what people consider to be a good constrained crypto implementation that is publicly available, and hopefully can be compiled to run on my non-constrained system. If people want to give me suggestions please do so privately. Jim From nobody Wed Feb 17 22:07: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 1230F1B3472 for ; Wed, 17 Feb 2016 22:07:13 -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 XEmvvRjxm-zq for ; Wed, 17 Feb 2016 22:07:10 -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 E9E351B3326 for ; Wed, 17 Feb 2016 22:07:09 -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 575F92C9F3; Wed, 17 Feb 2016 22:07:09 -0800 (PST) From: "Jim Schaad" To: "'Francesca Palombini'" , References: <20160208042145.24820.37300.idtracker@ietfa.amsl.com> <001801d16229$41c9a410$c55cec30$@augustcellars.com> <56B895CA.8060104@mit.edu> In-Reply-To: Date: Wed, 17 Feb 2016 22:04:36 -0800 Message-ID: <00fd01d16a12$3f012410$bd036c30$@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: AQE71YXHLsFdxJ2tXd79Peo2WUxLeAJ5LnsHAlTpIb0CFmPdmKAlURmw Archived-At: Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10.txt 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, 18 Feb 2016 06:07:13 -0000 Except for the issue of the new appendix A the pull request @ https://github.com/cose-wg/cose-spec/pull/140 There are a couple of notes below, but I did not comment on anything that was not odd. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Francesca Palombini > Sent: Friday, February 12, 2016 8:17 AM > To: Justin Richer ; cose@ietf.org; Jim Schaad > > Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10.txt > > Hi Jim and all, > > I have quickly reviewed the last version of the draft and I have a couple of > remarks. > Most of them are editorial and typos I noticed, but I also have some more > important questions. > > Starting with the Important Stuff: > > In our Object Security implementation, we use an identifier that identifies a set > of parameters related to protection of the message, as for example algorithm, > replay protection parameters, keys (possibly more than one) and others. We call > this "Context Identifier". This parameter is sent in the message. > Following many discussion (live and by mail), we agreed on using the COSE "kid" > parameter to contain this identifier, and we haven't gotten any objection for it. > Now, while reviewing the last version of the draft, I noticed in the kid definition > (Section 3.1): > > "The value of this parameter is matched against the 'kid' member in a COSE_Key > structure." > > This is clearly non-compliant with our use of the "kid" header field. I see three > solutions to solve this: > - Have a new parameter that complies with our context identifier (more > general identifier for security related set of parameters) > - "Soften" the definition of "kid": in practical terms, modify this sentence > so to have what was the previous version: > > "The value of this parameter _can be_ matched against the 'kid' member in a > COSE_Key structure." I have modified this. > > - Add an appendix about the use of the "kid", explaining that it can be > used in other ways (although this is not the "default" use). I don't think an appendix is a reasonable option for this. I have added an application specific comment to the description of 'kid' instead > > Second question: I didn't see any decision about alg. Is there finally going to be > an appendix considering the case where alg is omitted from the COSE message > and following considerations about it? > > The editorials comments: > > Section 2: > point 4: consider replacing "in a CoAP message" with "in a CoAP payload" if you > mean Content-Format by content type parameter. > > Section 3: > "[...] most of the algorithms that are used for recipients do not provide for > authenticated data and thus the bucket should not be used." Missing word(s)? > > Section 3.1: > "This parameter one of the ways that can be used to find the key to be used." > Missing word(s)? > > Section 4.1: > "[...] and a counter- signature." Shouldn't it be "and the counter- signature" (if it > is an example of parameter about the signature)? Otherwise it is unclear. I have been going back and forth on the question of counter signatures. There is no reason, in theory, that there cannot be more than one counter signature and the current syntax allows for this (oops - only in one place) but I did change the sentence. > > Section 4.3: > "so that if they cannot be modified in transit it can be detected." Replace > "cannot be" with "are". > > signing and verification = very clear > Section 4.4: > point 4. of signing: consider adding the sentence: "(See Section 4.3 for > application guidance on constructing this field.)" as it is done in section 5.2 point > 4. > point 4. of verifying: about the text "Place the resulting signature value in the > 'signature' field of the map.", this is correct for COSE_Signature, but COSE_Sign1 > is not a map. Actually, map is wrong for both of them. > > Section 4.5: > "This means that the Sig_structure can be used for in a uniform manner to get > the byte stream for processing a signature." Delete first "for"? > > Section 5.2: > "Examples of encrypted messages can be found in Appendix C.3." Should be C.4 > > Section 5.3 > Is it possible to get section 5.3 similar in structure to 4.4 and 6.3? I would like the > numbered list to be the order of the fields in the array (take out the text in point > 1.) > Point 5. "Encode the Enc_structure using a CBOR Canonical encoding Section > 14 to get the AAD value." Reference in parenthesis? > There is no "decryption/verification" section following encryption. Can you add > some specification about that? (Analogous to the verification part of Section > 4.4) > > Section 6.3: > Same here, there is no verification section for MAC either. Can you add some > specification about that? > > Section 15: > "Applications need to determine the set of messages defined in this document > that it will be using." replace "it" with "they" (or "An application needs ..." > "When applications use externally defined authenticated data, they need to > define how that data is to be defined." Consider replace "is to be defined" with > "is to be constructed" (sounds better to me) > > Section 17: > "While some considerations have been highlighted here, additional > considerations may be found in the documents referred to that have full details > of the algorithm." Not very clear to me, maybe add a comma after "referred > to"? Or consider rephrasing. > "Using a the same key for two different algorithms can leak" Remove "a". > "A number of factors are assoicated with this trust decision." I think you meant > "associated" > "What are the permissions assoicated with the key owner?" Same here. > "been checked are are correct?" Probably "and are correct" > > General: > Consider adding references to examples in Appendix C.2 and C.6 (There is no > reference to these examples in the text). > > Otherwise, closed issues are OK. > > Best regards, > Francesca > > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Justin Richer > Sent: den 8 februari 2016 14:19 > To: cose@ietf.org > Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-10.txt > > Hello everybody, > > Please review the list of completed issues in the tracker against the new version > of the document: > > https://github.com/cose-wg/cose- > issues/issues?q=is%3Aissue+is%3Aopen+label%3AComplete > > We will close all issues marked as "Complete" in one week if there is no > contention on the issue. > > -- Justin, your COSE chair > > On 2/7/2016 11:29 PM, Jim Schaad wrote: > > This version should address all of the open issues in the tracker except for the > optional algorithm pair of items (#51 and #52). > > There are two issues that are still unmarked as resolved that are > > probably not of great importance > > > > #54 is only important to the OSCoAP people if they are not planning to > > use the CBOR content type option > > #53 went out for comment at the start of January and gathered crickets > (except for a comment of that would be nice from Stephen Ferrell). > > > > Ilari - Once upon a time you made a comment about the context structure and > the header fields that can optionally be used for population of it. I have since > done a couple of passes trying to do a re-write on it to make things clearer. Can > you please check if your issue (current CREF2) has been resolve? > > > > Jim > > > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Sunday, February 07, 2016 8:22 PM > >> To: Jim Schaad > >> Subject: New Version Notification for draft-ietf-cose-msg-10.txt > >> > >> > >> A new version of I-D, draft-ietf-cose-msg-10.txt has been > >> successfully submitted by Jim Schaad and posted to the IETF repository. > >> > >> Name: draft-ietf-cose-msg > >> Revision: 10 > >> Title: CBOR Encoded Message Syntax > >> Document date: 2016-02-07 > >> Group: cose > >> Pages: 105 > >> URL: https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-10.txt > >> Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > >> Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-10 > >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-10 > >> > >> Abstract: > >> Concise Binary Object Representation (CBOR) is data format designed > >> for small code size and small message size. There is a need for the > >> ability to have the basic security services defined for this data > >> format. This document specifies processing for signatures, message > >> authentication codes, and encryption using CBOR. This document also > >> specifies a representation for cryptographic keys using CBOR. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at tools.ietf.org. > >> > >> The IETF Secretariat > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Wed Feb 24 07:19: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 B5A3D1B315D for ; Wed, 24 Feb 2016 07:19:37 -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 Xr9uwaCodOcc for ; Wed, 24 Feb 2016 07:19:35 -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 6288E1B32FE for ; Wed, 24 Feb 2016 07:19:35 -0800 (PST) Date: Wed, 24 Feb 2016 07:19:34 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1456327174; bh=+66hha66ES04hXCiNb9Ctz/6U54hvuhXLseYLxhP29w=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1S6vOLO+wRIsQCHgaMykXHje3kN13xVBS8JUHa2ldfEvrdq9jYua8xKFm1Yrei3Rq zz5/BmjTg/bWc4yV6bgns7bAodrlKrAVNvuacYHRyVi8ZYQxxiCOhLCRfM85eKgPdA 7PwsgdbFTYz2SkRHBgQVOYQ8GxqN/vhVoPFWNu+w= From: fpalombini To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_56cdca064caef_19683f93222d92a014792dd"; 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: Re: [COSE] [cose-issues] Define a key parameter for IV (#61) 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: Wed, 24 Feb 2016 15:19:37 -0000 ----==_mimepart_56cdca064caef_19683f93222d92a014792dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I think it would definitely be useful to have an (optional) IV field in the COSE_Key structure. If it is not defined in COSE, it could still be defined by the application, as I assume you mean by writing: * label => values in COSE_Key CDDL definition. If it is the case, I think there should be some text specifying that the application can define more fields. If it isn't and I interpreted the CDDL wrong, then I am strongly in favor of defining the IV field in COSE_Key, and removing (or explaining) that line of the CDDL COSE_Key structure. --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/61#issuecomment-188302975 ----==_mimepart_56cdca064caef_19683f93222d92a014792dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

I think it would definitely be useful to have an (optional) IV field in the COSE_Key structure.

If it is not defined in COSE, it could still be defined by the application, as I assume you mean by writing:

  • label => values in COSE_Key CDDL definition. If it is the case, I think there should be some text specifying that the application can define more fields. If it isn't and I interpreted the CDDL wrong, then I am strongly in favor of defining the IV field in COSE_Key, and removing (or explaining) that line of the CDDL COSE_Key structure.

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

----==_mimepart_56cdca064caef_19683f93222d92a014792dd--