Skip to main content

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

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