Re: [COSE] draft-jones-cose-rsa

[Mike Jones <[e-mail]>]

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



-----Original Message-----
From: jose [mailto:[e-mail]] On Behalf Of Jim Schaad
Sent: Sunday, January 01, 2017 3:34 PM
To: [e-mail]
Cc: [e-mail]
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.



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.



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.


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.



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