All good thanks, S.
On 19/02/15 16:23, Pete Resnick wrote: > On 2/19/15 9:55 AM, Stephen Farrell wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> Last time this came around I had the comments below. >> While Barry no longer has a DISCUSS, I'd still be >> interested in chatting a bit about these. (Apologies >> that I've not had time to re-read the draft though, so >> feel free to just tell me these comments are OBE if >> that's the case.) >> >> " >> - I agree with Bary's discuss - it seems weird to not >> have the initial registries in hand when the RFC is >> being issued. People will, I guess, implement from >> Appendix A here anyway, so why not either delete this >> and get the registry in place, or else make Appendix A >> be the initial registry content. >> > > OBE. We changed the whole way this was done. > >> 7.7: This uses the empty set, which is puzzling. I think >> you mean that this set is to be populated by the DE in >> the IANA registries but if so, saying so would be good. >> > > OBE. Section changed to make this clear. > >> 10.5: This says that a) its all too hard but also b) >> "Nevertheless, specifications for application protocols >> that use this framework MUST describe how confusable >> characters can be abused to compromise the security of >> systems that use the protocol in question, along with any >> protocol-specific suggestions for overcoming those >> threats." That seems like a 6919 MUST (but we know you >> won't) to me. Is that a good plan? >> > > Changed "MUST" to "are strongly encouraged to" > >> 10.6: Prompted by the secdir review, it might be worth a >> few words on password hashing, which is very common. E.g. >> say that the canonical form is input to hashing and >> therefore just can't be mucked about with. (But say that >> nicely:-) >> > > Added: > > In protocols that provide passwords as input to a cryptographic > algorithm such as a hash function, the client will need to perform > proper preparation of the password before applying the algorithm, > since the password is not available to the server in plaintext form. > > I hope that addresses everything. > > pr > _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
