| Dhruv:
Thanks for the review. Reviewer: Dhruv Dhody
Review result: Has Nits
# OPSDIR review of draft-ietf-lamps-rfc5990bis-05
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in the last call may be
included in AD reviews during the IESG review. Document editors and WG chairs
should treat these comments just like any other last-call comments.
The document specifies the conventions for using the RSA-KEM Algorithm The
document is clear and well-written. The draft does not have any operational
text which is to be expected of such a document. The document is almost ready
for publication, I have only minor concerns and nits.
## Minor
- It is unusual to mention a draft name in the abstract. Perhaps change that to
RFC XXXX and add a note to the RFC editor that XXXX should be replaced with the
RFC# assigned to the draft.
Yes. That document is already in the RFC Editor's queue. It will have an RFC number before this document is published. - Abstract should also note that the RFC 5990 is being obsoleted and highlight
the change/motivation.
I agree that the Abstract should say: "This document obsoletes RFC 5990." However, the changes since RFC 5990 section already tackles the reasons. - The text does not state what is e in "c = z^e mod n" or d in "z = ct^d mod
n", should it?
I think that the reference to Section 3 of [RFC8017] explains e, d, and n as part of the RSA key generation. I think that a summary here would incomplete. Note that RFC 5990 did the same. - Section 1.6; Once this I-D is published, the RFC 5990 will be obsoleted and
thus I suggest we rephrase "RFC 5990 uses...", "RFC 5990 includes", etc to
indicate RFC 5990 is in the past...
Agree. - Throughout the I-D there are various MUST conditions, it is unsure to me what
happens when those conditions are not met.
Some of the MUST statements are needed to properly implement RSA-KEM. One has implemented a different (probably less secure) algorithm if the MUST statements are not follow, especially these:
The RSA-KEM Algorithm provides a fixed-length ciphertext. The recipient MUST check that the received byte string is the expected length and the expected length and corresponds to an integer in the expected range prior to attempting decryption with their RSA private key as described in Steps 1 and 2 of Appendix A.2.
- Appendix A uses the notation "(C)" for ciphertext whereas the rest of the
text uses "ct". Is that okay?
To avoid confusion, I will use ct throughout. - Section A.1, step 2 - "Encrypt the random integer Z..."; shouldn't this be z
instead of Z. I see RFC 5099 used z. Why was that changed?
RFC 5990 uses both z and Z.
Z = IntegerToString (z, nLen) ## Nits
- s/with goal of providing/with the goal of providing/
- s/Decrypt the the ciphertext with the/Decrypt the ciphertext with the/
- Expand on first use - KDF
- s/used with with the RSA-KEM/used with the RSA-KEM/
- s/using the their private key/using their private key/
All of these were fixed. Thanks for the careful read.
Russ
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
