Hi. On Sat, 2013-03-23 at 11:56 +0100, Yngve N. Pettersen wrote: > Hi, > > Thanks for the review .. and thanks for the rapid response!
Couple of comments in line below.. I've snipped the agreed stuff. Regards, Elwyn > > On Fri, 22 Mar 2013 01:41:48 +0100, Elwyn Davies <[email protected]> > 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-multiple-cert-status-extension-04.txt > > Reviewer: Elwyn Davies > > Review Date: 22 March 2013 > > IETF LC End Date: 29 March 2013 > > IESG Telechat date: (if known) - > > > > Summary: Almost ready for IESG - one possible minor issue relating to > > the alleged criterion for ordering CertificateStatusRequestItems plus a > > number of nits that are mainly missing cross references and notes for > > clarity about updates of RFC 6066 items. > > > > Major issues: > > None > > > > Minor issues: > > s2.2: > >> The list of CertificateStatusRequestItem entries MUST be in order of > >> preference. > > Having thought a bit about this, I cannot identify what the preference > > criterion is - this may be because I don't understand the problem, but I > > think you need to explain what the criterion is if there really is one. > > If there *is* a criterion, it must be clear whether the order is most > > preferred first or least preferred first. Since I don't know what the > > criterion is, I can't tell if there are any security implications from > > the ordering: no chance of downgrade attacks? > > The list is ordered by the client, based on whatever criteria its > developer uses. These criteria can be based on objective evaluation of > each available method, or personal opinions about them. > > I have now clarified this sentence to be similar to the ciphersuite list > language in RFC 5246 > > New text: "The list of CertificateStatusRequestItem entries MUST be in > order of the client's preference (favorite choice first)." > > The server could still ignore that ordering when it picks the method to > use (for the ones it knows). OK that explains the criterion. However, as in the cipher suite list in RFC 5246, using a requirements MUST is inappropriate as it is not a testable protocol condition. I think what you are trying to get over is that the *server* SHOULD work from beginning to end of the list giving higher priority to items earlier in the list so that the client's desires are satisfied as far as possible. > For example if there is only one OCSP > response available for a chain, e.g because there is no intermediate or > the intermediate does not have an OCSP responder assigned, then it would > be overkill to use the multiple OCSP variant, so the single response > version would be used instead. Does this need some words then? > > > Nits/editorial comments: <<snip>> > > s2.2, para 4 on page 5: > >> In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560 > >> <http://tools.ietf.org/html/rfc2560>] is > >> unclear about its encoding; for clarification,..... > > This probably needs to be flagged up in the IANA considerations so that > > an additional reference is added to the registry. > > ALSO I subsequently noted that this same caveat is already in RFC 6066. > > Consider referring to the caveat there rather than duplicating it. > > This language is, as you mention, a copy of the RFC 6066 note about this > problem. > > I think it is better to duplicate it, since it is so small. A longer and > more complex section would probably have been referenced, but adding such > references for small informational text would IMO make the document less > readable. Fair enough - and I realize this isn't an IANA matter. However, if this is an issue for RFC 2560, shouldn't somebody file an erratum? I couldn't see anything about this in the current set of errata. <<snip>> _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
