Hi Jouni, thanks for your review. Please find my response inline:
On 11/30/2015 04:46 AM, Jouni wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-tls-cached-info-20 Reviewer: Jouni Korhonen > Review Date: 2015-11-29 IETF LC End Date: 2015-12-04 IESG Telechat > date: 2015-12-17 > > > Summary: -------- > > Ready for publication with some nits. > > Comments: --------- > > The document was good read and easy to understand. > > Minor issues/nits: ------------------ > > * IDnits spits out some warning & comments that all seem to be bogus. > However, the normative reference to RFC 4634 needs to be replaced > with RFC 6234. Fixed. > > * The document describes in few places how the mechanisms specified > extends/updates the Certificate and CertificateRequest structures. So > maybe the draft should also state that in its boilerplate “Updates: > 5246, 7250” ? > I believe it only explains the interworking with other, related specifications but it does not really update them. Regarding RFC 7250: With RFC 7250 the Certificate payload may contain a SubjectPublicKeyInfo payload rather than a certificate. I wanted to point this out in the description. Regarding RFC 5246: The specification re-uses existing TLS 1.2 payloads and defines extensions for them but it does not change the behavior of the underlying TLS 1.2 mechanism. > * Line 99: s/its’/its OK. > > * Line 164: s/data\.\./data\. OK. > > * Section 5 talks about “input data” for the hash & fingerprint > calculation. What the “input data” exactly is becomes obvious after > reading the Appendix A. However, for non-TLS WG activist it was not > obvious from the first sight. Suggest adding a forward reference to > Appendix A example. Fine with me. > > * Section 6 uses [0], [1], .. [4]. While these are perfectly correct > they can be mixed with references in the first sight -> few seconds > of confusion ;) I would suggest using (0), .. (4). Sounds reasonable. > > * The document uses referencing all styles “RFC 7250 [RFC7250]”, “RFC > 7250” and “[RFC7250]”. Pick one. Ok. > > * It is unclear to me what happens & what are the procedures when two > different “input data”s generate the same fingerprint. Since the client caches information previously provided by the server, such as the certificate, it is the server that can detect that such a collision can occur. If it occurs the server operator has two options, namely not to use the extension or to resolve the conflict. Does this description make sense? Ciao Hannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
