Skip to main content

Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS)
draft-ietf-lamps-rfc5990bis-10

Yes

Deb Cooley

No Objection

Erik Kline
Francesca Palombini
Jim Guichard
John Scudder
Zaheduzzaman Sarker

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

Deb Cooley
Yes
Paul Wouters
(was Discuss) Yes
Comment (2024-06-05 for -08) Sent
Thanks for addressing my concerns. I've updated my ballot to Yes
Erik Kline
No Objection
Francesca Palombini
No Objection
Gunter Van de Velde
No Objection
Comment (2024-05-07 for -06) Not sent
# Gunter Van de Velde, RTG AD, comments for draft-ietf-lamps-rfc5990bis-06

idnits spits up normative references to informational rfc
Jim Guichard
No Objection
John Scudder
No Objection
Murray Kucherawy
No Objection
Comment (2024-05-15 for -06) Not sent
I support Paul's DISCUSS position.
Orie Steele
No Objection
Comment (2024-04-29 for -05) Sent
# Orie Steele, ART AD, comments for draft-ietf-lamps-rfc5990bis-05 
CC @OR13

This review is in the ["IETF Comments" Markdown format][ICMF].
You can use the [`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues, or using this [online validator](https://mnot.github.io/ietf-comments/).

Line numbers are generated with this:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-rfc5990bis-05.txt&submitcheck=True

## Comments

### key pair reuse with other algorithms

```
563	   Accordingly, an RSA key pair used for the RSA-KEM Algorithm SHOULD
564	   NOT also be used for digital signatures.  Indeed, the Accredited
565	   Standards Committee X9 (ASC X9) requires such a separation between
566	   key pairs used for key establishment and key pairs used for digital
567	   signature [ANS-X9.44].  Continuing this principle of key separation,
568	   a key pair used for the RSA-KEM Algorithm SHOULD NOT be used with
569	   other key establishment schemes, or for data encryption, or with more
570	   than one set of underlying algorithm components.
```

Since separation is mentioned here, there does not appear to be any context binding in Encap / Decap via the KDF at that layer, or in Derive KEK after.

I wonder if there was discussion of binding the kem algorithm id into KDF(ss).

Is there a scenario where a key pair used for the RSA-KEM Algorithm SHOULD / MUST be used with other key establishment schemes, or for data encryption, or with more than one set of underlying algorithm components?

Why not MUST NOT?

## Nits

### digitalSignatrure

```
424	   The digitalSignatrure and dataEncipherment values SHOULD NOT be
```

Spelling.
Roman Danyliw
No Objection
Comment (2024-05-12 for -06) Not sent
Thank you to Christer Holmberg for the GENART review.
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment (2024-05-10 for -06) Sent
Thanks for the work done in this document, it seems indeed that a refresh was needed.

Just 2 comments

`First, the input to the underlying RSA operation is a string-encoded random integer between 0 and n-1, where n is the RSA modulus, so it does not have any structure that could be exploited by an adversary.` does the length of this random number give some clue to the attacker ?

3rd paragraph of the security considerations have several SHOULD without any indication when those SHOULD can be bypassed.