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.