Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages
draft-jones-cose-rsa-05

Note: This ballot was opened for revision 04 and is now closed.

Kathleen Moriarty Yes

Alia Atlas No Objection

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2017-06-21 for -04)
6.1: I wonder if "highly recommended" in paragraph 2 and "should not be used" in paragraph 3 warrant 2119 keywords.

6.3, paragraph 2: I wonder the same about "Keys used with RSAES-OAEP must follow the constraints...". But it's not clear to me whether this creates a new requirement to follow the constraints in 3447, or it it just references an existing requirement from 3447.

Benoit Claise No Objection

Alissa Cooper No Objection

Spencer Dawkins No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Mirja K├╝hlewind No Objection

Terry Manderson No Objection

Alexey Melnikov No Objection

Eric Rescorla No Objection

Comment (2017-06-19 for -04)
This document seems sound overall. A few points which I believe
would improve it.

- The Private Key format seems like a straight translation of
  RFC 8017's RSAPrivateKey but the explanation of the various
  parameters in 8017 is a lot clearer. E.g.,
  "exponent1 is d mod (p - 1)." versus "first factor CRT Exponent"
  I would advice making the direct connection to 8017 and
  adopting their descriptions.

- Is it really wise to be standardizing RSA-OAEP with SHA-1
  at this point? I'm not claiming that there is a real attack,
  but we are generally trying to not do anything new with
  SHA-1.

"
      value 32,768 is represented as the CBOR byte sequence 0b010_00010
      (major type 2, additional information 2 for the length), 0x80
      0x00."

I found this text hard to follow. I believe it would be improved by
putting the parenthetical at the end rather than in the middle.


- S 6.3. Rather than just saying "low" you should specify exactly
  which ones you mean.

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2017-06-19 for -04)
The "must" and "must not" in the final paragraph of section 6.3 seem normative in their intention (and are presumably why [Boneh99] is listed as "normative" rather than "informative" in the references section). Given that the document is using 2119 language elsewhere, I would suggest capitalizing them for avoidance of doubt.

Please fix this nit:
  ** Obsolete normative reference: RFC 3447