Re: [Gen-art] Gen-art last call review of draft-ietf-tls-multiple-cert-status-extension-04

[Elwyn Davies <[e-mail]>]

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 <[e-mail]>
> 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>>