Hi again
On Sat, 23 Mar 2013 13:48:30 +0100, Elwyn Davies <[email protected]>
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 <[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.
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/
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
