[COSE] FW: [jose] draft-jones-cose-rsa
Jim Schaad <ietf@augustcellars.com> Mon, 09 January 2017 06:13 UTC
Return-Path: <ietf@augustcellars.com>
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 <cose@ietfa.amsl.com>; 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 <cose@ietfa.amsl.com>; 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 <cose@ietf.org>; 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 <ietf@augustcellars.com>
To: 'cose' <cose@ietf.org>
References: <012d01d26487$8fb4d080$af1e7180$@augustcellars.com>
In-Reply-To: <012d01d26487$8fb4d080$af1e7180$@augustcellars.com>
Date: Sun, 08 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: <https://mailarchive.ietf.org/arch/msg/cose/2yYolWs-EZijF_GH_U39t8hKIZM>
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 <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=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
- [COSE] FW: [jose] draft-jones-cose-rsa Jim Schaad
- Re: [COSE] FW: [jose] draft-jones-cose-rsa Justin Richer
- Re: [COSE] FW: [jose] draft-jones-cose-rsa Kathleen Moriarty
- Re: [COSE] FW: [jose] draft-jones-cose-rsa Mike Jones
- Re: [COSE] draft-jones-cose-rsa Mike Jones
- Re: [COSE] draft-jones-cose-rsa Jim Schaad
- Re: [COSE] draft-jones-cose-rsa Mike Jones