From nobody Sun Jan 8 02:29:34 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B625A126D73 for ; Sun, 8 Jan 2017 02:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXYghJxzDY2Z for ; Sun, 8 Jan 2017 02:29:31 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 574741293E3 for ; Sun, 8 Jan 2017 02:29:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 7C0D8180F4; Sun, 8 Jan 2017 12:29:29 +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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 0SF9-RiD_ElC; Sun, 8 Jan 2017 12:29:28 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id A0729283; Sun, 8 Jan 2017 12:29:28 +0200 (EET) Date: Sun, 8 Jan 2017 12:29:17 +0200 From: Ilari Liusvaara To: Mike Jones Message-ID: <20170108102917.GA9896@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] Using RSA Algorithms with COSE Messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 10:29:34 -0000 On Sat, Dec 31, 2016 at 09:27:36PM +0000, Mike Jones wrote: > The specification Using RSA Algorithms with COSE Messages defines encodings for using RSA algorithms with CBOR Object Signing and Encryption (COSE) messages. This supports use cases for the FIDO Alliance and others that need this functionality. Security Area Director Kathleen Moriarty has agreed to AD sponsorship of this specification. This specification incorporates text from draft-ietf-cose-msg-05 - the last COSE specification version before the RSA algorithms were removed. > > The specification is available at: > > * https://tools.ietf.org/html/draft-jones-cose-rsa-01 > > An HTML-formatted version is also available at: > > * http://self-issued.info/docs/draft-jones-cose-rsa-01.html > > Review feedback is welcomed! Just as a note, I impilemented the key storage format (for a test of one feature[1] in TLS lib I'm working on). Supported fields: 1 (value must be 3), 2 (ignored), 3 (-37, -38 and -39 only if present), 4 (must cotain 1 if present), -1 to -8 (all required), all others trigger an error (and also unexpected types for known fields).. ~450 lines of Rust code[2], including CBOR/key parsing, public key export and lowering signing requests to Ring (a BoringSSL fork with Rust API). [1] Extensible support for keypair formats. [2] The binary (.so) size is quite big (~1.4MB) due to static linkage of Rust standard library and RSA signing code from Ring. -Ilari From nobody Sun Jan 8 22:13:40 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634E0129AFC for ; Sun, 8 Jan 2017 22:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBFixFUl68KE for ; Sun, 8 Jan 2017 22:13:36 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B844129AF0 for ; Sun, 8 Jan 2017 22:13:36 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 8 Jan 2017 22:33:00 -0800 From: Jim Schaad To: 'cose' References: <012d01d26487$8fb4d080$af1e7180$@augustcellars.com> In-Reply-To: <012d01d26487$8fb4d080$af1e7180$@augustcellars.com> Date: Sun, 8 Jan 2017 22:13:22 -0800 Message-ID: <009a01d26a3f$7ccc1880$76644980$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHltIzhQUxu96+6SuJDi5Wk7eLvtKEJFbew Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [COSE] FW: [jose] draft-jones-cose-rsa X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 06:13:38 -0000 I just figure out that I sent this to the wrong list - maybe the names are too close together. > -----Original Message----- > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Sunday, January 01, 2017 3:34 PM > To: draft-jones-cose-rsa@tools.ietf.org > Cc: jose@ietf.org > Subject: [jose] draft-jones-cose-rsa > > Comments: > > 0. Should this be done in curdle rather than as AD sponsored? > > 1. As per previous mail, remove values assignments in tables 1, 2, and 3 unless > you have cleared them with the appropriate registry experts. I am less worried > about table 4 but you should clear that as well. > > 2. Kill RSAES-OAP w/ SHA-1. We are not doing SHA-1 currently with any of the > CBOR algorithms. In section 3.1.1.1 - what are the properties that are needed > here for SHA-1 so we can ensure that the statement is true. Also, rename this to > be s/ SHA-1 not w/ Default. There are no defaults for COSE. > > 3. Text in 3.1.1.1 and 2.1.1 should be more consistent in how it is written. > > 4. in the abstract be more specific about which RSA algorithms are being > supported. For example, you are not doing 1.5 or KEM. > > 5. Why does 3.1.1.1 have a size and 2.1.1 not have one. This should be > consistent. > > 6. section 3.1.1.1 should be encryption operation not decryption operation. > > 7. Section 3.1.1.1 - this text does not make sense "One potential denial of > service > operation is to provide encrypted objects using either abnormally > long or oddly sized RSA modulus values." Should probably refer to keys > not encrypted objects. > > 8. There is a requirement of minimum encoding lengths - what purpose does > this serve? Is there a security problem here or is it just a nice to have because of > message size? > > 9. Missing some security considerations. > > 10 Section 2.1.1 s/hash functions are not truncated/hash function outputs are > not truncated/ > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From nobody Mon Jan 9 11:38:39 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB40129DC6 for ; Mon, 9 Jan 2017 11:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wgne3o97f61U for ; Mon, 9 Jan 2017 11:38:35 -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 D7F6B129DC5 for ; Mon, 9 Jan 2017 11:38:33 -0800 (PST) X-AuditID: 12074423-25bff70000000d21-31-5873e6b7efa6 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id C3.AD.03361.7B6E3785; Mon, 9 Jan 2017 14:38:32 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v09JcVQh005916; Mon, 9 Jan 2017 14:38:31 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v09JcTcu013548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Jan 2017 14:38:30 -0500 To: Jim Schaad , "'cose'" References: <012d01d26487$8fb4d080$af1e7180$@augustcellars.com> <009a01d26a3f$7ccc1880$76644980$@augustcellars.com> From: Justin Richer Message-ID: Date: Mon, 9 Jan 2017 14:38:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <009a01d26a3f$7ccc1880$76644980$@augustcellars.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixCmqrbvjWXGEQVO7pMW0rVNZLVZP/87m wOSxcc50No8lS34yBTBFcdmkpOZklqUW6dslcGU8aDnEUvBbqKJzzgrWBsZG/i5GTg4JAROJ ydMnsnQxcnEICbQxSdzqWsMK4WxglPjy6Dg7hHObSeLpxWMsIC3CAsYStye8ZwWxRQQcJVY8 amcHsYUESiW2rPnFCGKzCahKTF/TwgRi8wpYSVxb1AdWzyKgIjFn8mKwelGBGIm365ezQ9QI Spyc+QRsPqeAg8T0lyfA5jAL2ErcmbubGcKWl9j+dg7zBEb+WUhaZiEpm4WkbAEj8ypG2ZTc Kt3cxMyc4tRk3eLkxLy81CJdM73czBK91JTSTYygkGR3Ud7B+LLP+xCjAAejEg/vhknFEUKs iWXFlbmHGCU5mJREeQ12AYX4kvJTKjMSizPii0pzUosPMUpwMCuJ8Po/BcrxpiRWVqUW5cOk pDlYlMR5L2W6RwgJpCeWpGanphakFsFkZTg4lCR49UAaBYtS01Mr0jJzShDSTBycIMN5gIa3 gg0vLkjMLc5Mh8ifYlSUEudNBUkIgCQySvPgekEpI+HtYdNXjOJArwjzfnoCVMUDTDdw3a+A BjMBDY60AxtckoiQkmpgZM8UK647YSxRWB8y9Rfv5tt/VHfMeFHcMaHng6nQlLXszPMb1gcd jdkqtP5Xi8qJT/orGV5vXa/0IVdH5ivP/y4WxcrPQWXiTNPiCnPKozRj/Je4q697v33rx2/r qwKCPNTE9edd9Y5e8fTHzF2GXXbVSTrZXTc6b9164M58Z55kd++zmLt3lViKMxINtZiLihMB 2ZknPfQCAAA= Archived-At: Subject: Re: [COSE] FW: [jose] draft-jones-cose-rsa X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 19:38:37 -0000 +1 on the CURDLE question. -- Justin On 1/9/2017 1:13 AM, Jim Schaad wrote: > I just figure out that I sent this to the wrong list - maybe the names are > too close together. > >> -----Original Message----- >> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad >> Sent: Sunday, January 01, 2017 3:34 PM >> To: draft-jones-cose-rsa@tools.ietf.org >> Cc: jose@ietf.org >> Subject: [jose] draft-jones-cose-rsa >> >> Comments: >> >> 0. Should this be done in curdle rather than as AD sponsored? >> >> 1. As per previous mail, remove values assignments in tables 1, 2, and 3 > unless >> you have cleared them with the appropriate registry experts. I am less > worried >> about table 4 but you should clear that as well. >> >> 2. Kill RSAES-OAP w/ SHA-1. We are not doing SHA-1 currently with any of > the >> CBOR algorithms. In section 3.1.1.1 - what are the properties that are > needed >> here for SHA-1 so we can ensure that the statement is true. Also, rename > this to >> be s/ SHA-1 not w/ Default. There are no defaults for COSE. >> >> 3. Text in 3.1.1.1 and 2.1.1 should be more consistent in how it is > written. >> 4. in the abstract be more specific about which RSA algorithms are being >> supported. For example, you are not doing 1.5 or KEM. >> >> 5. Why does 3.1.1.1 have a size and 2.1.1 not have one. This should be >> consistent. >> >> 6. section 3.1.1.1 should be encryption operation not decryption > operation. >> 7. Section 3.1.1.1 - this text does not make sense "One potential denial > of >> service >> operation is to provide encrypted objects using either abnormally >> long or oddly sized RSA modulus values." Should probably refer to > keys >> not encrypted objects. >> >> 8. There is a requirement of minimum encoding lengths - what purpose does >> this serve? Is there a security problem here or is it just a nice to have > because of >> message size? >> >> 9. Missing some security considerations. >> >> 10 Section 2.1.1 s/hash functions are not truncated/hash function outputs > are >> not truncated/ >> >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Jan 9 11:49:57 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87241294F0 for ; Mon, 9 Jan 2017 11:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK0P5DApbAbn for ; Mon, 9 Jan 2017 11:49:53 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 79AAD129551 for ; Mon, 9 Jan 2017 11:49:53 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id s140so129377601qke.0 for ; Mon, 09 Jan 2017 11:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4dqOm+gPIdnizbYD2ZD9mj6LICMRcWSK5oqGB3EScwQ=; b=ZoGL3oRxdl2KiZD4dM/yt7BHw+2SgRaj2aV/MP5m1becdHm0nVzvfr1M5W3zroII6B npy6pXvA7Z0wxQ1JVobjIuMfGR7kOHjMrQlIlSzUvtZruOS9JJK3bt0n/iX7JgeXuDZH uewVzYsg9+6802lEdCMScXGrON+HBITta4iH2CptPjPU/k7LmirAwVUfjTajXBiBu5Ff mA2ydmqSlCym/wSFcXAm0U91ldMhAYlqH+KCdzaEUqfupUo0ufkRlZ8C4mT5sb4NOh/e ncCWw6KfQnT+PpoHJTC6e/81cdoqAoZFAFP6aSbHOZn/T4ekwaunk0/k12XuytUPwBbg iLDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4dqOm+gPIdnizbYD2ZD9mj6LICMRcWSK5oqGB3EScwQ=; b=IRewZOjvPYZnJ8zb7T+5r8eJGj69PfrRRCJMRMH9nId3RXj6gldpHgh9hwodkS0IgU MBuPSCUR77NiNbR8wcRlfkbdtC9sDte2YZcR8WofmhGlFpwytL5iY8ndm+idRZL1LL3w J3U4B8r49XYPg7ZEZjnA20ucKRfA3QJL3Zl4GjC+lQo8VNH3kE4a4PzDoYUtPECfqspu VNAVy3XKVOyRMLSlDj+rEgcDVZJYY0WnxPOjgEYipza9jGm9R4vrxNiLjG/YmaGbqaaQ sgYlKq/r0liv6MNo7q/2C/BYPHnItw08yztjuIBcnejhTJX7iMe7C+51vpukhgV9bifi weDQ== X-Gm-Message-State: AIkVDXLiudcqOMqNtyed1GBC1qKU0dgQhX/jnRq8B8yBXUPgfrGhNhKN4HZ0ArDwQ4POan++sgLDpec0w2RKMA== X-Received: by 10.55.9.15 with SMTP id 15mr88210873qkj.118.1483991392627; Mon, 09 Jan 2017 11:49:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.161.101 with HTTP; Mon, 9 Jan 2017 11:49:52 -0800 (PST) In-Reply-To: References: <012d01d26487$8fb4d080$af1e7180$@augustcellars.com> <009a01d26a3f$7ccc1880$76644980$@augustcellars.com> From: Kathleen Moriarty Date: Mon, 9 Jan 2017 14:49:52 -0500 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a114c8472ceb1470545aeab1e Archived-At: Cc: Jim Schaad , cose Subject: Re: [COSE] FW: [jose] draft-jones-cose-rsa X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 19:49:55 -0000 --001a114c8472ceb1470545aeab1e Content-Type: text/plain; charset=UTF-8 If the work can be done in a WG, that is preferred. On Mon, Jan 9, 2017 at 2:38 PM, Justin Richer wrote: > +1 on the CURDLE question. > > -- Justin > > > > On 1/9/2017 1:13 AM, Jim Schaad wrote: > >> I just figure out that I sent this to the wrong list - maybe the names are >> too close together. >> >> -----Original Message----- >>> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad >>> Sent: Sunday, January 01, 2017 3:34 PM >>> To: draft-jones-cose-rsa@tools.ietf.org >>> Cc: jose@ietf.org >>> Subject: [jose] draft-jones-cose-rsa >>> >>> Comments: >>> >>> 0. Should this be done in curdle rather than as AD sponsored? >>> >>> 1. As per previous mail, remove values assignments in tables 1, 2, and 3 >>> >> unless >> >>> you have cleared them with the appropriate registry experts. I am less >>> >> worried >> >>> about table 4 but you should clear that as well. >>> >>> 2. Kill RSAES-OAP w/ SHA-1. We are not doing SHA-1 currently with any >>> of >>> >> the >> >>> CBOR algorithms. In section 3.1.1.1 - what are the properties that are >>> >> needed >> >>> here for SHA-1 so we can ensure that the statement is true. Also, rename >>> >> this to >> >>> be s/ SHA-1 not w/ Default. There are no defaults for COSE. >>> >>> 3. Text in 3.1.1.1 and 2.1.1 should be more consistent in how it is >>> >> written. >> >>> 4. in the abstract be more specific about which RSA algorithms are being >>> supported. For example, you are not doing 1.5 or KEM. >>> >>> 5. Why does 3.1.1.1 have a size and 2.1.1 not have one. This should be >>> consistent. >>> >>> 6. section 3.1.1.1 should be encryption operation not decryption >>> >> operation. >> >>> 7. Section 3.1.1.1 - this text does not make sense "One potential denial >>> >> of >> >>> service >>> operation is to provide encrypted objects using either abnormally >>> long or oddly sized RSA modulus values." Should probably refer to >>> >> keys >> >>> not encrypted objects. >>> >>> 8. There is a requirement of minimum encoding lengths - what purpose >>> does >>> this serve? Is there a security problem here or is it just a nice to >>> have >>> >> because of >> >>> message size? >>> >>> 9. Missing some security considerations. >>> >>> 10 Section 2.1.1 s/hash functions are not truncated/hash function outputs >>> >> are >> >>> not truncated/ >>> >>> >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> >> _______________________________________________ >> 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 > -- Best regards, Kathleen --001a114c8472ceb1470545aeab1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If the work can be done in a WG, that is preferred.
<= div class=3D"gmail_extra">
On Mon, Jan 9, 201= 7 at 2:38 PM, Justin Richer <jricher@mit.edu> wrote:
+1 on the CURDLE question.<= font color=3D"#888888">

=C2=A0-- Justin



On 1/9/2017 1:13 AM, Jim Schaad wrote:
I just figure out that I sent this to the wrong list - maybe the names are<= br> too close together.

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

Comments:

0.=C2=A0 Should this be done in curdle rather than as AD sponsored?

1.=C2=A0 As per previous mail, remove values assignments in tables 1, 2, an= d 3
unless
you have cleared them with the appropriate registry experts.=C2=A0 I am les= s
worried
about table 4 but you should clear that as well.

2.=C2=A0 Kill RSAES-OAP w/ SHA-1.=C2=A0 We are not doing SHA-1 currently wi= th any of
the
CBOR algorithms.=C2=A0 In section 3.1.1.1 - what are the properties that ar= e
needed
here for SHA-1 so we can ensure that the statement is true.=C2=A0 Also, ren= ame
this to
be s/ SHA-1 not w/ Default.=C2=A0 There are no defaults for COSE.

3.=C2=A0 Text in 3.1.1.1 and 2.1.1 should be more consistent in how it is
written.
4. in the abstract be more specific about which RSA algorithms are being supported.=C2=A0 For example, you are not doing 1.5 or KEM.

5.=C2=A0 Why does 3.1.1.1 have a size and 2.1.1 not have one.=C2=A0 This sh= ould be
consistent.

6.=C2=A0 section 3.1.1.1 should be encryption operation not decryption
operation.
7.=C2=A0 Section 3.1.1.1 - this text does not make sense "One potentia= l denial
of
service
=C2=A0 =C2=A0 operation is to provide encrypted objects using either abnorm= ally
=C2=A0 =C2=A0 long or oddly sized RSA modulus values."=C2=A0 =C2=A0Sho= uld probably refer to
keys
not encrypted objects.

8.=C2=A0 There is a requirement of minimum encoding lengths - what purpose = does
this serve?=C2=A0 Is there a security problem here or is it just a nice to = have
because of
message size?

9. Missing some security considerations.

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




_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
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



--
=

Best regards,
Kathleen
--001a114c8472ceb1470545aeab1e-- From nobody Mon Jan 9 12:02:52 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC49129575 for ; Mon, 9 Jan 2017 12:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89dzNr4jZ3-3 for ; Mon, 9 Jan 2017 12:02:48 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0114.outbound.protection.outlook.com [104.47.33.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 A164C128824 for ; Mon, 9 Jan 2017 12:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7oduI/m7ytRG8bWLMKDxhW0Xek99bZRn9qUbQddNv0E=; b=LOkf2UovIRH+W/IS6XZsvvPZqB4RB15wwS+zDHLEh6n4JzYFN9YW9vsGHexWxMpWW3OpN08vrZcTU0YUs7OHhaWJwQfIQoPbWurnwxjRQCptfqxh3RKEwexCKh+QGVDks5xxM2WEcxst6gXLiTEiIO2x3+BiWlIAcnWRZaUyIH4= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2354.namprd03.prod.outlook.com (10.166.74.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Mon, 9 Jan 2017 20:02:46 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0803.021; Mon, 9 Jan 2017 20:02:46 +0000 From: Mike Jones To: Kathleen Moriarty , Justin Richer Thread-Topic: [COSE] FW: [jose] draft-jones-cose-rsa Thread-Index: AdJj3G5A8Mg3MokbT1CbCGHSigaDpAGYwxgAABwd2wAAAGY5AAAAVeoQ Date: Mon, 9 Jan 2017 20:02:46 +0000 Message-ID: References: <012d01d26487$8fb4d080$af1e7180$@augustcellars.com> <009a01d26a3f$7ccc1880$76644980$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [107.18.133.67] x-ms-office365-filtering-correlation-id: 9e9dfc85-b792-4744-c14f-08d438ca7b22 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2354; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2354; 7:4HpOD91fNwNZDAdTDD8Ednk1tySgNbDaw4aAy+WfCXiH8UsYqap/Ci3MMDeU02X5/Um9BldPhajlXRP6YNgnUHxHSUJnd7tpL36bhtcn+nNcP+q8OodTQbkzeEqhe5c8OzgPrfpKlxi4dQFKvkkMSyg5So+K7tQAyGrePIP6U617H7tx0MsHLTeoWWobfIURterFEjseIEeKvbEHteOGbqISXASSp0c5W74e4paU+jmMGv9S47H/ulj48yqUAO6ve6E8mvAb2mhvp3AEa4wMsm7kjEDMDZOkcRTKIanzw075GykV3TnVxlLYWKqpyGEvWHfmFsrrUM/4cofoBnw/L/X5F1fcR9URu38dx9FfFJAiNK1tRWwfnIeLuubxRCIzMvzOUrmOznCrXtFshQPmDpir3l+gBh9W9Sq+MVMQJPuWwy/N3KourfF5QCM/wb8GlxIrqOFrH1Iersy0lzDBKFmgRQjRA6LQS/82wwjLIlw= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6047074)(6072148); SRVR:BN3PR03MB2354; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2354; x-forefront-prvs: 0182DBBB05 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39410400002)(39850400002)(39840400002)(39860400002)(189002)(13464003)(24454002)(199003)(377454003)(8990500004)(3846002)(39060400001)(7906003)(3660700001)(2171001)(74316002)(81156014)(54356999)(81166006)(8676002)(19609705001)(55016002)(99286003)(68736007)(33656002)(101416001)(50986999)(8936002)(3280700002)(66066001)(229853002)(92566002)(4326007)(7696004)(86612001)(10090500001)(105586002)(86362001)(54896002)(7736002)(54906002)(6306002)(76176999)(122556002)(5005710100001)(2906002)(9686003)(6506006)(93886004)(230783001)(38730400001)(77096006)(2900100001)(189998001)(5660300001)(5001770100001)(10290500002)(6436002)(2950100002)(790700001)(102836003)(97736004)(6116002)(25786008)(106356001)(606005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2354; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB2355979876F156F04847CFC0F5640BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2017 20:02:46.3294 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2354 Archived-At: Cc: Jim Schaad , cose Subject: Re: [COSE] FW: [jose] draft-jones-cose-rsa X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 20:02:51 -0000 --_000_BN3PR03MB2355979876F156F04847CFC0F5640BN3PR03MB2355namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYWQgcmVxdWVzdGVkIEFEIHNwb25zb3JzaGlwIGJlY2F1c2Ugb2YgaG93IHNpbXBsZSB0aGUg ZHJhZnQgaXMuICBJdCByZWdpc3RlcnMgYSBmZXcgbnVtYmVycyBpbiByZWdpc3RyaWVzIGJlaW5n IGNyZWF0ZWQgYnkgdGhlIENPU0UgTWVzc2FnZXMgZHJhZnQgYW5kIGRlZmluZXMgdGhlIGxheW91 dCBvZiBSU0Ega2V5cyAoaW4gYSB3YXkgdGhhdOKAmXMgY29tcGxldGVseSBwYXJhbGxlbCB0byB0 aGUgSk9TRSBsYXlvdXQsIGJ1dCB1c2luZyBDQk9SIHJhdGhlciB0aGFuIEpTT04pLiAgSXQgdXNl cyBubyBuZXcgYWxnb3JpdGhtcy4gIEl0IGRpZG7igJl0IHNlZW0gdG8gcmlzZSB0byB0aGUgb2Nj YXNpb24gb2YgbmVlZGluZyBhIHdvcmtpbmcgZ3JvdXAg4oCTIGVzcGVjaWFsbHkgd2hlbiB0aGVy ZSByZW1haW4gQ09TRSBXRyBtZW1iZXJzIHN1Y2ggYXMgSmltIHdpbGxpbmcgdG8gdGFrZSB0aGUg dGltZSB0byBnaXZlIGNvbnN0cnVjdGl2ZSBmZWVkYmFjay4NCg0KQlRXLCBJIHBsYW4gdG8gcmVz cG9uZCB0byBKaW3igJlzIG5vdGUgaW4gZGV0YWlsIGxhdGVyIGluIHRoZSB3ZWVrLiAgRm9yIHRo ZSBmaXJzdCBoYWxmIG9mIHRoZSB3ZWVrLCBJ4oCZbSBvbiBhbm90aGVyIG1lZGljYWwgc29qb3Vy biBmb3IgbXkgd2lmZSBpbiBCb3N0b24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBDaGVlcnMsDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBDT1NFIFtt YWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2F0aGxlZW4gTW9yaWFy dHkNClNlbnQ6IE1vbmRheSwgSmFudWFyeSA5LCAyMDE3IDExOjUwIEFNDQpUbzogSnVzdGluIFJp Y2hlciA8anJpY2hlckBtaXQuZWR1Pg0KQ2M6IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFy cy5jb20+OyBjb3NlIDxjb3NlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDT1NFXSBGVzogW2pv c2VdIGRyYWZ0LWpvbmVzLWNvc2UtcnNhDQoNCklmIHRoZSB3b3JrIGNhbiBiZSBkb25lIGluIGEg V0csIHRoYXQgaXMgcHJlZmVycmVkLg0KDQpPbiBNb24sIEphbiA5LCAyMDE3IGF0IDI6MzggUE0s IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4g d3JvdGU6DQorMSBvbiB0aGUgQ1VSRExFIHF1ZXN0aW9uLg0KDQogLS0gSnVzdGluDQoNCg0KDQpP biAxLzkvMjAxNyAxOjEzIEFNLCBKaW0gU2NoYWFkIHdyb3RlOg0KSSBqdXN0IGZpZ3VyZSBvdXQg dGhhdCBJIHNlbnQgdGhpcyB0byB0aGUgd3JvbmcgbGlzdCAtIG1heWJlIHRoZSBuYW1lcyBhcmUN CnRvbyBjbG9zZSB0b2dldGhlci4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBq b3NlIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpqb3NlLWJvdW5jZXNAaWV0 Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSmltIFNjaGFhZA0KU2VudDogU3VuZGF5LCBKYW51YXJ5IDAx LCAyMDE3IDM6MzQgUE0NClRvOiBkcmFmdC1qb25lcy1jb3NlLXJzYUB0b29scy5pZXRmLm9yZzxt YWlsdG86ZHJhZnQtam9uZXMtY29zZS1yc2FAdG9vbHMuaWV0Zi5vcmc+DQpDYzogam9zZUBpZXRm Lm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtqb3NlXSBkcmFmdC1qb25lcy1j b3NlLXJzYQ0KDQpDb21tZW50czoNCg0KMC4gIFNob3VsZCB0aGlzIGJlIGRvbmUgaW4gY3VyZGxl IHJhdGhlciB0aGFuIGFzIEFEIHNwb25zb3JlZD8NCg0KMS4gIEFzIHBlciBwcmV2aW91cyBtYWls LCByZW1vdmUgdmFsdWVzIGFzc2lnbm1lbnRzIGluIHRhYmxlcyAxLCAyLCBhbmQgMw0KdW5sZXNz DQp5b3UgaGF2ZSBjbGVhcmVkIHRoZW0gd2l0aCB0aGUgYXBwcm9wcmlhdGUgcmVnaXN0cnkgZXhw ZXJ0cy4gIEkgYW0gbGVzcw0Kd29ycmllZA0KYWJvdXQgdGFibGUgNCBidXQgeW91IHNob3VsZCBj bGVhciB0aGF0IGFzIHdlbGwuDQoNCjIuICBLaWxsIFJTQUVTLU9BUCB3LyBTSEEtMS4gIFdlIGFy ZSBub3QgZG9pbmcgU0hBLTEgY3VycmVudGx5IHdpdGggYW55IG9mDQp0aGUNCkNCT1IgYWxnb3Jp dGhtcy4gIEluIHNlY3Rpb24gMy4xLjEuMSAtIHdoYXQgYXJlIHRoZSBwcm9wZXJ0aWVzIHRoYXQg YXJlDQpuZWVkZWQNCmhlcmUgZm9yIFNIQS0xIHNvIHdlIGNhbiBlbnN1cmUgdGhhdCB0aGUgc3Rh dGVtZW50IGlzIHRydWUuICBBbHNvLCByZW5hbWUNCnRoaXMgdG8NCmJlIHMvIFNIQS0xIG5vdCB3 LyBEZWZhdWx0LiAgVGhlcmUgYXJlIG5vIGRlZmF1bHRzIGZvciBDT1NFLg0KDQozLiAgVGV4dCBp biAzLjEuMS4xIGFuZCAyLjEuMSBzaG91bGQgYmUgbW9yZSBjb25zaXN0ZW50IGluIGhvdyBpdCBp cw0Kd3JpdHRlbi4NCjQuIGluIHRoZSBhYnN0cmFjdCBiZSBtb3JlIHNwZWNpZmljIGFib3V0IHdo aWNoIFJTQSBhbGdvcml0aG1zIGFyZSBiZWluZw0Kc3VwcG9ydGVkLiAgRm9yIGV4YW1wbGUsIHlv dSBhcmUgbm90IGRvaW5nIDEuNSBvciBLRU0uDQoNCjUuICBXaHkgZG9lcyAzLjEuMS4xIGhhdmUg YSBzaXplIGFuZCAyLjEuMSBub3QgaGF2ZSBvbmUuICBUaGlzIHNob3VsZCBiZQ0KY29uc2lzdGVu dC4NCg0KNi4gIHNlY3Rpb24gMy4xLjEuMSBzaG91bGQgYmUgZW5jcnlwdGlvbiBvcGVyYXRpb24g bm90IGRlY3J5cHRpb24NCm9wZXJhdGlvbi4NCjcuICBTZWN0aW9uIDMuMS4xLjEgLSB0aGlzIHRl eHQgZG9lcyBub3QgbWFrZSBzZW5zZSAiT25lIHBvdGVudGlhbCBkZW5pYWwNCm9mDQpzZXJ2aWNl DQogICAgb3BlcmF0aW9uIGlzIHRvIHByb3ZpZGUgZW5jcnlwdGVkIG9iamVjdHMgdXNpbmcgZWl0 aGVyIGFibm9ybWFsbHkNCiAgICBsb25nIG9yIG9kZGx5IHNpemVkIFJTQSBtb2R1bHVzIHZhbHVl cy4iICAgU2hvdWxkIHByb2JhYmx5IHJlZmVyIHRvDQprZXlzDQpub3QgZW5jcnlwdGVkIG9iamVj dHMuDQoNCjguICBUaGVyZSBpcyBhIHJlcXVpcmVtZW50IG9mIG1pbmltdW0gZW5jb2RpbmcgbGVu Z3RocyAtIHdoYXQgcHVycG9zZSBkb2VzDQp0aGlzIHNlcnZlPyAgSXMgdGhlcmUgYSBzZWN1cml0 eSBwcm9ibGVtIGhlcmUgb3IgaXMgaXQganVzdCBhIG5pY2UgdG8gaGF2ZQ0KYmVjYXVzZSBvZg0K bWVzc2FnZSBzaXplPw0KDQo5LiBNaXNzaW5nIHNvbWUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMu DQoNCjEwIFNlY3Rpb24gMi4xLjEgcy9oYXNoIGZ1bmN0aW9ucyBhcmUgbm90IHRydW5jYXRlZC9o YXNoIGZ1bmN0aW9uIG91dHB1dHMNCmFyZQ0Kbm90IHRydW5jYXRlZC8NCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFpbGluZyBs aXN0DQpqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KQ09TRSBtYWlsaW5nIGxpc3QNCkNPU0VAaWV0Zi5vcmc8bWFp bHRvOkNPU0VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Nvc2UNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkNPU0UgbWFpbGluZyBsaXN0DQpDT1NFQGlldGYub3JnPG1haWx0bzpDT1NFQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQoNCg0KDQotLQ0KDQpC ZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0K --_000_BN3PR03MB2355979876F156F04847CFC0F5640BN3PR03MB2355namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPkkgaGFkIHJlcXVlc3RlZCBBRCBzcG9uc29yc2hpcCBiZWNhdXNlIG9mIGhvdyBzaW1w bGUgdGhlIGRyYWZ0IGlzLiZuYnNwOyBJdCByZWdpc3RlcnMgYSBmZXcgbnVtYmVycyBpbiByZWdp c3RyaWVzIGJlaW5nIGNyZWF0ZWQgYnkgdGhlIENPU0UgTWVzc2FnZXMgZHJhZnQgYW5kIGRlZmlu ZXMgdGhlIGxheW91dCBvZiBSU0Ega2V5cyAoaW4gYSB3YXkgdGhhdOKAmXMgY29tcGxldGVseQ0K IHBhcmFsbGVsIHRvIHRoZSBKT1NFIGxheW91dCwgYnV0IHVzaW5nIENCT1IgcmF0aGVyIHRoYW4g SlNPTikuJm5ic3A7IEl0IHVzZXMgbm8gbmV3IGFsZ29yaXRobXMuJm5ic3A7IEl0IGRpZG7igJl0 IHNlZW0gdG8gcmlzZSB0byB0aGUgb2NjYXNpb24gb2YgbmVlZGluZyBhIHdvcmtpbmcgZ3JvdXAg 4oCTIGVzcGVjaWFsbHkgd2hlbiB0aGVyZSByZW1haW4gQ09TRSBXRyBtZW1iZXJzIHN1Y2ggYXMg SmltIHdpbGxpbmcgdG8gdGFrZSB0aGUgdGltZSB0byBnaXZlIGNvbnN0cnVjdGl2ZQ0KIGZlZWRi YWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+QlRXLCBJIHBsYW4gdG8g cmVzcG9uZCB0byBKaW3igJlzIG5vdGUgaW4gZGV0YWlsIGxhdGVyIGluIHRoZSB3ZWVrLiZuYnNw OyBGb3IgdGhlIGZpcnN0IGhhbGYgb2YgdGhlIHdlZWssIEnigJltIG9uIGFub3RoZXIgbWVkaWNh bCBzb2pvdXJuIGZvciBteSB3aWZlIGluIEJvc3Rvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDaGVl cnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4g Q09TRSBbbWFpbHRvOmNvc2UtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+ S2F0aGxlZW4gTW9yaWFydHk8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDksIDIw MTcgMTE6NTAgQU08YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0 LmVkdSZndDs8YnI+DQo8Yj5DYzo8L2I+IEppbSBTY2hhYWQgJmx0O2lldGZAYXVndXN0Y2VsbGFy cy5jb20mZ3Q7OyBjb3NlICZsdDtjb3NlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW0NPU0VdIEZXOiBbam9zZV0gZHJhZnQtam9uZXMtY29zZS1yc2E8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSB3b3JrIGNhbiBiZSBkb25lIGluIGEgV0csIHRoYXQg aXMgcHJlZmVycmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gTW9uLCBKYW4gOSwgMjAxNyBhdCAyOjM4IFBNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBo cmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQu ZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+JiM0MzsxIG9uIHRoZSBDVVJETEUgcXVlc3Rpb24uPHNwYW4gc3R5bGU9ImNv bG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPiZuYnNwOy0tIEp1 c3Rpbjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCk9uIDEvOS8yMDE3IDE6MTMgQU0sIEppbSBT Y2hhYWQgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGp1c3QgZmlndXJlIG91dCB0aGF0 IEkgc2VudCB0aGlzIHRvIHRoZSB3cm9uZyBsaXN0IC0gbWF5YmUgdGhlIG5hbWVzIGFyZTxicj4N CnRvbyBjbG9zZSB0b2dldGhlci48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IGpvc2Ug W21haWx0bzo8YSBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+am9zZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEppbSBTY2hhYWQ8 YnI+DQpTZW50OiBTdW5kYXksIEphbnVhcnkgMDEsIDIwMTcgMzozNCBQTTxicj4NClRvOiA8YSBo cmVmPSJtYWlsdG86ZHJhZnQtam9uZXMtY29zZS1yc2FAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5kcmFmdC1qb25lcy1jb3NlLXJzYUB0b29scy5pZXRmLm9yZzwvYT48YnI+DQpDYzog PGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5qb3NlQGlldGYu b3JnPC9hPjxicj4NClN1YmplY3Q6IFtqb3NlXSBkcmFmdC1qb25lcy1jb3NlLXJzYTxicj4NCjxi cj4NCkNvbW1lbnRzOjxicj4NCjxicj4NCjAuJm5ic3A7IFNob3VsZCB0aGlzIGJlIGRvbmUgaW4g Y3VyZGxlIHJhdGhlciB0aGFuIGFzIEFEIHNwb25zb3JlZD88YnI+DQo8YnI+DQoxLiZuYnNwOyBB cyBwZXIgcHJldmlvdXMgbWFpbCwgcmVtb3ZlIHZhbHVlcyBhc3NpZ25tZW50cyBpbiB0YWJsZXMg MSwgMiwgYW5kIDM8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnVubGVzczxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnlvdSBoYXZlIGNsZWFyZWQgdGhlbSB3aXRoIHRoZSBhcHByb3ByaWF0ZSByZWdpc3Ry eSBleHBlcnRzLiZuYnNwOyBJIGFtIGxlc3M8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPndvcnJpZWQ8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hYm91dCB0YWJsZSA0IGJ1dCB5b3Ugc2hvdWxkIGNsZWFy IHRoYXQgYXMgd2VsbC48YnI+DQo8YnI+DQoyLiZuYnNwOyBLaWxsIFJTQUVTLU9BUCB3LyBTSEEt MS4mbmJzcDsgV2UgYXJlIG5vdCBkb2luZyBTSEEtMSBjdXJyZW50bHkgd2l0aCBhbnkgb2Y8bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZTxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNCT1IgYWxnb3Jp dGhtcy4mbmJzcDsgSW4gc2VjdGlvbiAzLjEuMS4xIC0gd2hhdCBhcmUgdGhlIHByb3BlcnRpZXMg dGhhdCBhcmU8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPm5lZWRlZDxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmhlcmUgZm9yIFNIQS0xIHNvIHdlIGNhbiBlbnN1cmUgdGhhdCB0aGUgc3RhdGVtZW50IGlz IHRydWUuJm5ic3A7IEFsc28sIHJlbmFtZTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhpcyB0bzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJlIHMvIFNIQS0xIG5vdCB3LyBEZWZhdWx0LiZuYnNwOyBU aGVyZSBhcmUgbm8gZGVmYXVsdHMgZm9yIENPU0UuPGJyPg0KPGJyPg0KMy4mbmJzcDsgVGV4dCBp biAzLjEuMS4xIGFuZCAyLjEuMSBzaG91bGQgYmUgbW9yZSBjb25zaXN0ZW50IGluIGhvdyBpdCBp czxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d3Jp dHRlbi48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40 LiBpbiB0aGUgYWJzdHJhY3QgYmUgbW9yZSBzcGVjaWZpYyBhYm91dCB3aGljaCBSU0EgYWxnb3Jp dGhtcyBhcmUgYmVpbmc8YnI+DQpzdXBwb3J0ZWQuJm5ic3A7IEZvciBleGFtcGxlLCB5b3UgYXJl IG5vdCBkb2luZyAxLjUgb3IgS0VNLjxicj4NCjxicj4NCjUuJm5ic3A7IFdoeSBkb2VzIDMuMS4x LjEgaGF2ZSBhIHNpemUgYW5kIDIuMS4xIG5vdCBoYXZlIG9uZS4mbmJzcDsgVGhpcyBzaG91bGQg YmU8YnI+DQpjb25zaXN0ZW50Ljxicj4NCjxicj4NCjYuJm5ic3A7IHNlY3Rpb24gMy4xLjEuMSBz aG91bGQgYmUgZW5jcnlwdGlvbiBvcGVyYXRpb24gbm90IGRlY3J5cHRpb248bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9wZXJhdGlvbi48bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj43LiZuYnNwOyBTZWN0 aW9uIDMuMS4xLjEgLSB0aGlzIHRleHQgZG9lcyBub3QgbWFrZSBzZW5zZSAmcXVvdDtPbmUgcG90 ZW50aWFsIGRlbmlhbDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+b2Y8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5zZXJ2aWNlPGJyPg0KJm5ic3A7ICZuYnNwOyBvcGVyYXRpb24gaXMgdG8gcHJvdmlkZSBl bmNyeXB0ZWQgb2JqZWN0cyB1c2luZyBlaXRoZXIgYWJub3JtYWxseTxicj4NCiZuYnNwOyAmbmJz cDsgbG9uZyBvciBvZGRseSBzaXplZCBSU0EgbW9kdWx1cyB2YWx1ZXMuJnF1b3Q7Jm5ic3A7ICZu YnNwO1Nob3VsZCBwcm9iYWJseSByZWZlciB0bzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+a2V5czxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPm5vdCBlbmNyeXB0ZWQgb2JqZWN0cy48YnI+DQo8YnI+DQo4 LiZuYnNwOyBUaGVyZSBpcyBhIHJlcXVpcmVtZW50IG9mIG1pbmltdW0gZW5jb2RpbmcgbGVuZ3Ro cyAtIHdoYXQgcHVycG9zZSBkb2VzPGJyPg0KdGhpcyBzZXJ2ZT8mbmJzcDsgSXMgdGhlcmUgYSBz ZWN1cml0eSBwcm9ibGVtIGhlcmUgb3IgaXMgaXQganVzdCBhIG5pY2UgdG8gaGF2ZTxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YmVjYXVzZSBvZjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1lc3NhZ2Ug c2l6ZT88YnI+DQo8YnI+DQo5LiBNaXNzaW5nIHNvbWUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMu PGJyPg0KPGJyPg0KMTAgU2VjdGlvbiAyLjEuMSBzL2hhc2ggZnVuY3Rpb25zIGFyZSBub3QgdHJ1 bmNhdGVkL2hhc2ggZnVuY3Rpb24gb3V0cHV0czxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXJlPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+bm90IHRydW5jYXRlZC88YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCmpvc2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5qb3NlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZTwvYT48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ09TRSBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86Q09TRUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkNPU0VAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb3NlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpDT1NFIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpDT1NFQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Q09TRUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2U8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkthdGhsZWVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR03MB2355979876F156F04847CFC0F5640BN3PR03MB2355namp_-- From nobody Fri Jan 13 14:55:05 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4741299A6 for ; Fri, 13 Jan 2017 14:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98wLG2X1QnKC for ; Fri, 13 Jan 2017 14:55:00 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0139.outbound.protection.outlook.com [104.47.37.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED15129972 for ; Fri, 13 Jan 2017 14:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CT3hJ3CLBMmycouhLxAZchjt9sGidjt4PsKqDbhUubY=; b=emzaIF09T+Qp5xw0AzL4tLkxaT/+eQ2SiKTO/lb3LROV0vZsJFDKNklsdc6DGq2aroOBTFLkz4cJkvIjbkQ4g+h2zSUtfeL4BXEn4r4xEZ2FceHbxDgp8lggJm1D+AkmD5a6bmPYwfuHQ04RTREweslKsQ0bsAXzVz9RV+vMrRA= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2353.namprd03.prod.outlook.com (10.166.74.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Fri, 13 Jan 2017 22:54:57 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0845.013; Fri, 13 Jan 2017 22:54:57 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: draft-jones-cose-rsa Thread-Index: AdJt8A6WCR6ocoRXTl2j84aobKNTqQ== Date: Fri, 13 Jan 2017 22:54:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:f::7c0] x-ms-office365-filtering-correlation-id: b1eac37d-9dca-4c3e-f0c4-08d43c073277 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2353; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2353; 7:17AtrpD1WGKjSUIxU8xuLcJS9aKf2K6fXnLQbh3dbpZzroHTPOQoW0C5seQcnqvoo+b2sa8nisuC8Xi4B2AbBhrRcqOhaHAuvBmUPxChPTluMLH9BJlNVU34jl6tLvB7uxOQcKAWCiQJ1ZOMcdraMCD6IIkat8D2oJ/vfaazX9jNFt++HIsKbXWBM+XBSpODdUQl6Yy+2/fNxm5+rrwUVraKN0S2IG2qGIqrVCN59mONMtSMcFh8IfTHzaybdKwWS+HQ16c2BaajkhwBCgSZGeeU5NAJB0lPc+HxKIr1xNKNMSwkeggBy9+Cw3AoS0Ua5rx8lAc7HVJwcceIC2NRctZTVs7hn2geCaCVGqOmaBGbyFlcn8IN6CNVQfTbn9z9SroiMzG4RcrudfTHEZeFuri8sAWqT+DbZu1MAZiLx6CVRd8tv2VCA8TTizbOCSSaxcxr4wfpYzVu58poLsfw+PNrCTlOY7cz9I/mbAQLA5I= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074)(6042181); SRVR:BN3PR03MB2353; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2353; x-forefront-prvs: 018632C080 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(43784003)(199003)(189002)(13464003)(3660700001)(189998001)(229853002)(92566002)(86362001)(86612001)(38730400001)(2501003)(101416001)(106356001)(2900100001)(33656002)(6116002)(7736002)(102836003)(105586002)(790700001)(8676002)(74316002)(81166006)(8936002)(5660300001)(8990500004)(68736007)(54356999)(6506006)(4326007)(9686003)(81156014)(2906002)(55016002)(122556002)(7696004)(230783001)(99286003)(6436002)(54896002)(10090500001)(5001770100001)(3280700002)(6306002)(25786008)(50986999)(97736004)(77096006)(10290500002)(27001)(5005710100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2353; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB235550B5FC35228818245197F5780BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2017 22:54:57.3820 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2353 Archived-At: Cc: "draft-jones-cose-rsa@tools.ietf.org" Subject: Re: [COSE] draft-jones-cose-rsa X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:55:03 -0000 --_000_BN3PR03MB235550B5FC35228818245197F5780BN3PR03MB2355namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for taking the time to write this up, Jim. Responses are inline bel= ow. -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Sunday, January 01, 2017 3:34 PM To: draft-jones-cose-rsa@tools.ietf.org Cc: jose@ietf.org Subject: [jose] draft-jones-cose-rsa Comments: 0. Should this be done in curdle rather than as AD sponsored? I had requested AD sponsorship because of how simple the draft is. It regi= sters a few numbers in registries being created by the COSE Messages draft = and defines the layout of RSA keys (in a way that's completely parallel to = the JOSE layout, but using CBOR rather than JSON). It uses no new algorith= ms. It didn't seem to rise to the occasion of needing a working group - es= pecially when there remain COSE WG members such as Jim willing to take the = time to give constructive feedback. 1. As per previous mail, remove values assignments in tables 1, 2, and 3 u= nless you have cleared them with the appropriate registry experts. I am le= ss worried about table 4 but you should clear that as well. I looked for the designated experts to consult with but the IANA COSE regis= tries don't seem to have been created yet, nor have the experts been public= ly named. Once they are, I will certainly consult with them. I don't plan= to remove the values since having proposed assignments is more useful to i= mplementers than having none. 2. Kill RSAES-OAP w/ SHA-1. We are not doing SHA-1 currently with any of = the CBOR algorithms. In section 3.1.1.1 - what are the properties that are= needed here for SHA-1 so we can ensure that the statement is true. Also, = rename this to be s/ SHA-1 not w/ Default. There are no defaults for COSE. RSAES-OAEP with the default parameters defined in Section A.2.1 of RFC 3447= is included for the same reason that it is in RFC 7518 - because it's the = mostly widely implemented set of OAEP parameter choices, facilitating inter= operation of implementations. Particularly given that RSAES-PKCS1-v1_5 is = not included, RSA interop considerations lead to the decision to retain thi= s algorithm. In the next revision, I will be clear that the defaults come from RFC 3447. 3. Text in 3.1.1.1 and 2.1.1 should be more consistent in how it is writte= n. Suggestions for specific textual additions and/or changes would be helpful = here. 4. in the abstract be more specific about which RSA algorithms are being su= pported. For example, you are not doing 1.5 or KEM. OK - will do 5. Why does 3.1.1.1 have a size and 2.1.1 not have one. This should be co= nsistent. I agree with this suggestion. I'll make sure that the minimum size applies= to all uses of RSA algorithms. 6. section 3.1.1.1 should be encryption operation not decryption operation= . OK 7. Section 3.1.1.1 - this text does not make sense "One potential denial o= f service operation is to provide encrypted objects using either abnormally long or oddly sized RSA modulus values." Should probably refer to keys not encrypted objects. OK 8. There is a requirement of minimum encoding lengths - what purpose does = this serve? Is there a security problem here or is it just a nice to have = because of message size? This is there for the same reason that it is present for JWKs - to facilita= te interoperation of implementations by having a standard representation fo= r each key, rather enabling a multiplicity of different representations to = be used - which could cause interop problems. 9. Missing some security considerations. Specific suggested text would be appreciated, as always. 10 Section 2.1.1 s/hash functions are not truncated/hash function outputs a= re not truncated/ Agreed Thanks agai= n, -- Mike --_000_BN3PR03MB235550B5FC35228818245197F5780BN3PR03MB2355namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

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

 

Comments:

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

OK – will do

 

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

 

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

 

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

 

OK

 

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

   operation is to provide encrypted ob= jects using either abnormally

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

not encrypted objects.

 

OK

 

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

 

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

 

9. Missing some security considerations.

 

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

 

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

 

Agreed

 

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

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

 

--_000_BN3PR03MB235550B5FC35228818245197F5780BN3PR03MB2355namp_-- From nobody Fri Jan 13 21:46:46 2017 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1167C129880 for ; Fri, 13 Jan 2017 21:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W2ZgLpNUYin for ; Fri, 13 Jan 2017 21:46:42 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74069129446 for ; Fri, 13 Jan 2017 21:46:41 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 13 Jan 2017 22:09:42 -0800 From: Jim Schaad To: 'Mike Jones' , References: In-Reply-To: Date: Fri, 13 Jan 2017 21:46:32 -0800 Message-ID: <047c01d26e29$90adf600$b209e200$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_047D_01D26DE6.828CB1D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIZXa8Af/bdJgJiEwjsTavUjIGzsaCplM5A Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: draft-jones-cose-rsa@tools.ietf.org Subject: Re: [COSE] draft-jones-cose-rsa X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 05:46:45 -0000 ------=_NextPart_000_047D_01D26DE6.828CB1D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, January 13, 2017 2:55 PM To: Jim Schaad ; cose@ietf.org Cc: draft-jones-cose-rsa@tools.ietf.org Subject: RE: draft-jones-cose-rsa Thanks for taking the time to write this up, Jim. Responses are inline below. -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Sunday, January 01, 2017 3:34 PM To: draft-jones-cose-rsa@tools.ietf.org Cc: jose@ietf.org Subject: [jose] draft-jones-cose-rsa Comments: 0. Should this be done in curdle rather than as AD sponsored? I had requested AD sponsorship because of how simple the draft is. It registers a few numbers in registries being created by the COSE Messages draft and defines the layout of RSA keys (in a way that's completely parallel to the JOSE layout, but using CBOR rather than JSON). It uses no new algorithms. It didn't seem to rise to the occasion of needing a working group - especially when there remain COSE WG members such as Jim willing to take the time to give constructive feedback. [JLS] Getting people to from this old WG list can still be done even if it is done in a different working group. That is what the idea of cross posting is all about. Both individuals who have made substantive comments are on both mailing lists anyway so doing in a different group does not close out either of them. The amount of time a draft takes to finish depends as much on you as a chair for most steps. It is possible that the Curdle group would not want the draft, but asking is still reasonable. 1. As per previous mail, remove values assignments in tables 1, 2, and 3 unless you have cleared them with the appropriate registry experts. I am less worried about table 4 but you should clear that as well. I looked for the designated experts to consult with but the IANA COSE registries don't seem to have been created yet, nor have the experts been publicly named. Once they are, I will certainly consult with them. I don't plan to remove the values since having proposed assignments is more useful to implementers than having none. [JLS] For interop testing - that is what the private values are for. 2. Kill RSAES-OAP w/ SHA-1. We are not doing SHA-1 currently with any of the CBOR algorithms. In section 3.1.1.1 - what are the properties that are needed here for SHA-1 so we can ensure that the statement is true. Also, rename this to be s/ SHA-1 not w/ Default. There are no defaults for COSE. RSAES-OAEP with the default parameters defined in Section A.2.1 of RFC 3447 is included for the same reason that it is in RFC 7518 - because it's the mostly widely implemented set of OAEP parameter choices, facilitating interoperation of implementations. Particularly given that RSAES-PKCS1-v1_5 is not included, RSA interop considerations lead to the decision to retain this algorithm. In the next revision, I will be clear that the defaults come from RFC 3447. [JLS] There is absolutely no reason to even say that default values exist here. COSE does not have the concept of defaults. Not having SHA-1 does not seem to be a problem for PSS, why would it be a problem here? 3. Text in 3.1.1.1 and 2.1.1 should be more consistent in how it is written. Suggestions for specific textual additions and/or changes would be helpful here. 4. in the abstract be more specific about which RSA algorithms are being supported. For example, you are not doing 1.5 or KEM. OK - will do 5. Why does 3.1.1.1 have a size and 2.1.1 not have one. This should be consistent. I agree with this suggestion. I'll make sure that the minimum size applies to all uses of RSA algorithms. 6. section 3.1.1.1 should be encryption operation not decryption operation. OK 7. Section 3.1.1.1 - this text does not make sense "One potential denial of service operation is to provide encrypted objects using either abnormally long or oddly sized RSA modulus values." Should probably refer to keys not encrypted objects. OK 8. There is a requirement of minimum encoding lengths - what purpose does this serve? Is there a security problem here or is it just a nice to have because of message size? This is there for the same reason that it is present for JWKs - to facilitate interoperation of implementations by having a standard representation for each key, rather enabling a multiplicity of different representations to be used - which could cause interop problems. [JLS] Not sold. 9. Missing some security considerations. Specific suggested text would be appreciated, as always. 10 Section 2.1.1 s/hash functions are not truncated/hash function outputs are not truncated/ Agreed Thanks again, -- Mike ------=_NextPart_000_047D_01D26DE6.828CB1D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

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

 

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

 

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

 

Comments:

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

OK – will = do

 

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

 

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

 

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

 

OK

 

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

   operation is to provide encrypted = objects using either abnormally

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

not encrypted objects.

 

OK

 

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

 

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

 

[JLS] Not sold.

 

9. Missing some security = considerations.

 

Specific suggested text would be appreciated, as = always.

 

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

 

Agreed

 

        &nb= sp;           &nbs= p;            = ;            =             &= nbsp;      Thanks = again,

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

 

------=_NextPart_000_047D_01D26DE6.828CB1D0--