Skip to main content

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

Yes

(Kathleen Moriarty)

No Objection

Warren Kumari
(Alexey Melnikov)
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

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

Warren Kumari
No Objection
Kathleen Moriarty Former IESG member
Yes
Yes (for -04) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (2017-06-19 for -04) Unknown
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
Alexey Melnikov Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2017-06-21 for -04) Unknown
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 Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Eric Rescorla Former IESG member
No Objection
No Objection (2017-06-19 for -04) Unknown
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.
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -04) Unknown