Subject: [jose] draft-jones-cose-rsa

From: Jim Schaad <[email-masked]>
Date: Sun, 1 Jan 2017 15:34:11 -0800

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/

---

From: Mike Jones <[email-masked]>
Date: Fri, 13 Jan 2017 22:56:49 +0000

FYI, I replied to this on the COSE mailing list.

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Sunday, January 01, 2017 3:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: [jose] draft-jones-cose-rsa

Comments:

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.

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?

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

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose