Thank you for your work on this draft, apologies for taking so long to get to it (my queue exploded around IETF 125).
Deb ---------------------------------------- This is a fresh review of the whole draft (although I also looked at the diff w/ 8725): Shepherd's writeup: I will note that there are a couple of instances (#10 and #11) of 'updates RFC 8725', which might raise doubts, since 8725 is being replaced, i.e. 'obsoletes'. It might make sense to tweak that writeup a bit to be more precise. General: All SHOULD statements need to have statements about why one might ignore the SHOULD, or the risk incurred by ignoring the SHOULD. See https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ for more information. Please check for these. Abstract, para 2: swap 'replaces' with 'obsoletes'. Section 3.1, para 3: 'determine which algorithms are permitted for itself and that issuer', how does a recipient know a priori which algorithms an issuer permits? Is there a difference between 'recipient' and 'intended recipient'? Section 3.2, para 3: There are two instances of the word 'caller', literally the only two instances in the entire draft. Can we please use the same word to represent the sender/caller? [note: there is one instance of sender in section 2.6] Section 3.2, last para: I don't love the way this is stated. Perhaps 'Readers may want to be aware that [I-D.ietf-jose-deprecate-none-rsa15] may propose additional guidance on the "none" and "RSA1_5" algorithms.' I want it to be clearly informational, and I don't want the statement about whether or not it becomes an RFC (which won't age well). If the draft currently has additional guidance, then just say that, changing my suggestion of 'may propose' to 'does propose'. Section 3.5. using passwords to encrypt keys: I'm assuming this is still the current state of play? I will note that RFC 7518 points to even older RFC 2898 (which has been obsoleted by RFC 8018). I wonder if there was a way to make this section a little more current. Maybe by pointing to RFC 8018 directly? Section 3.13: The OWASP reference looks to be normative. Is that your intent? If not, then phrase it as an example and change the last sentence. Otherwise, make it normative, and remove the parenthetical that contains 'at the time of publishing'. ---------------------------------------------------
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
