[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