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

[Mike Jones <[e-mail]>]

Draft -02 incorporates the issue resolutions discussed below.  Thanks again for taking the time to do a thorough review, Jim.  Replies describing specific resolutions applied follow inline.

                                                       -- Mike

From: Jim Schaad [mailto:[e-mail]]
Sent: Friday, January 13, 2017 9:47 PM
To: Mike Jones <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: draft-jones-cose-rsa


From: Mike Jones [mailto:[e-mail]]
Sent: Friday, January 13, 2017 2:55 PM
To: Jim Schaad <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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:[e-mail]] On Behalf Of Jim Schaad
Sent: Sunday, January 01, 2017 3:34 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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.

[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.

[mbj] I seem to be getting useful feedback by posting the COSE list, as Kathleen had suggested.



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.



[mbj] I have left the proposed values in place, pending discussions with the designated experts, once they are announced.



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?

[mbj] As promised, I am now even clearer that they are RFC 3447-specified defaults.  The JOSE implementation experience with RSA-OAEP-SHA256 is that it's not available on many development platforms, whereas RSA-OAEP is.  Enabling implementers to use the defaults has interop benefits for COSE, just like it did for JOSE.


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.



[mbj] I have completely reworked and consolidated the Security Considerations in ways intended to address this feedback.



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

[mbj] Done


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.



[mbj] Addressed as part of restructuring the security considerations.



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


OK

[mbj] It now says "cryptographic operation", because the guidance now applies to signatures as well as encryption.


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

[mbj] Done (in reworked text)


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.



[mbj] Having a standard representation also reduces the variance in data formats that implementations have to parse, potentially improving interop.  Also, having a canonical representation has proven useful for JOSE.  I will likely prove useful for COSE for the same reasons.



9. Missing some security considerations.


Specific suggested text would be appreciated, as always.



[mbj] What would you like to see added?



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


Agreed



[mbj] Done



                                                                Thanks again,

                                                                -- Mike