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

[Jim Schaad <[e-mail]>]

 

 

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

 

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. 

 

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?

 

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.

 

[JLS] Not sold.

 

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