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

["Yngve N. Pettersen" <[e-mail]>]

Hi again

On Sat, 23 Mar 2013 13:48:30 +0100, Elwyn Davies <[e-mail]>  
wrote:

> 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.

The main information to get across is that the listed sequence is the  
client's order of preference, so that an implementor does not assume the  
ordering has no meaning.

Whether that require a MUST can probably be debated.

As mentioned, a server could decide to use its own ordering, but this  
would be at the cost of increasing complexity. A simple implementation  
would be to follow the client's ordering, and I think the preference for  
this is implied by stating that the ordering is the client's preference.

I have now tweaked the text a little further, removing the MUST:

"The items in the list of CertificateStatusRequestItem entries are in  
order of the client's preference (favorite choice first)."

Note: I am not quite satisfied with the wording here, and I think the  
grammar is not quite as it should be, and I am open to tweak suggestions.

>> 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?

At present I don't think so.

That kind of selection is an optimization that is available to the server  
implementor, if he wants to save a few bytes.

That option is implicit in that both modes are available in the  
definition. The server can pick whichever method works best.

Additionally, if/when other revocation methods, e.g. such as SCVP, are  
added, it is conceivable that the CA might limit the options available to  
the server, by not providing OCSP at all, which means that a client that  
prefer multiple ocsp before SCVP would still get SCVP because OCSP is not  
available.

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/