Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages
RFC 8230

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)
No email
send info
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.

(Benoît 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)
No email
send info
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

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

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)
No email
send info
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