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

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

Hi,

Thanks for the review

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

> Nits/editorial comments:
> s2:
> The presentation format used should be referenced back to s4 of RFC 5246.

Would probably be an idea. The reason it was left out is that RFC 6066
does not include such a reference.

I have now added a section 1.2 saying "This document defines protocol
structures using the same conventions and presentation language as defined
in Section 4 of [RFC 5246]"

> s2.1:
> A reference to s1.1 of RFC 6066 where extension_type is defined is
> needed, and it should be made more clear that this an expansion of the
> existing type.

Added a reference

> s2.2:
> A reference to s7.4.1.4 of RFC 5246 where extension_data is defined is
> needed.

Added a reference

> s2.2, page 4:
> Might be good to be more explicit that the definition of
> CertificateStatusRequest is an extension of the definition in RFC 6066.
> Also the definition of OSCPStatusRequest duplicates the one in RFC 6066
> and should be noted as such.  It would also be more appropriate if it
> came before CertificateStatusRequest as it is used in
> CertificateStatusRequest.

Added a reference

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

> s2.2, para 5 on page 5:
> s/A server that receive a client hello/A server that receives a client
> hello/

done

> s2.2, page 5/6:
> Might be good to be more explicit that the definition of
> CertificateStatus is an extension of the definition in RFC 6066.
> Also the definition of OSCPResponse duplicates the one in RFC 6066 and
> should be noted as such.  It would also be more appropriate if it came
> before CertificateStatus as it is used in CertificateStatus.

Added references "(originally defined by [RFC6066])".

> s2.2, page 6:
> The definition of OCSPResponseList should come before the redefinition
> of CertificateStatus as it is used in CertificateStatus.

There is actually, as far as I am able to tell, no established convention
in the TLS document family that the usage in a containing structure have
to be before the precise definition; e.g. see for example sections 7.4.2
and 7.4.3 in RFC 5246.

In fact, as a C/C++ programmer I very much prefer to have the included
structure defined before the usage (although that is not done in this
document).

> s2.2, para 2 after structure definitions on page 6:
> A reference to s7.4.2 of RFC 5246 for the Certificate list would be  
> helpful.

Inserted "[RFC5246] (Section 7.4.3)" before "Certificate" (I thought there
would be too many parentheses by adding it afterwards)



-- 
Sincerely,
Yngve N. Pettersen

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