Hi Hannes,
> On 21 Dec 2015, at 11:31, Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: > > 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. Ok. > > > >> * 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? Yes. You should probably add the above in some form to the draft. It is a good clarification. - Jouni > > Ciao > Hannes > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
