I am the assigned Gen-ART reviewer for draft-myers-ikev2-ocsp-03.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Summary
This draft is almost ready, but at the very least, item (5) below
requires action. The other items are suggested editorial improvements.
Details
(1) You may be asked to spell out some of the acronyms in the Abstract.
I'd suggest at least spelling out "CRL" and "OCSP".
(2) It looks like the Abstract evolved and pieces were tacked on over
time. It might read more smoothly with a bit of rearrangement, like this:
"Abstract
"When certificates are used with IKEv2, for example when using public
key based authentication (PKI), the communicating peers need a
mechanism to determine the revocation status of the peer's
certificate. The use of in-band Certificate Revocation Lists (CRLs)
is problematic due to unbounded CRL
size. The Online Certificate Status Protocol (OCSP) is an attractive
alternative, since the size of an OCSP response is well-bounded and
small. This document defines the "OCSP Content" extension to IKEv2.
A CERTREQ payload with "OCSP Content" identifies one or more trusted
OCSP responders and is a request for inclusion of an OCSP response in
the IKEv2 handshake. A cooperative recipient of such a request
responds with a CERT payload containing the appropriate OCSP
response. This content is recognizable via the same "OCSP Content"
identifier.
This document applies when
OCSP is desired and security policy prevents one of the IKEv2 peers
from accessing the relevant OCSP responder directly. Firewalls are
often deployed in a manner that prevents such access by IKEv2 peers
outside of an enterprise network."
(2) It would probably be a good idea to define the terms "OCSP request",
"OCSP response", and "OCSP responder" in the terminology section. I'm
especially concerned that the reader be aware that the term "OCSP
responder" does not refer to the party sending the CERT, but instead
takes its meaning from RFC 2560.
(3) I'd suggest that you avoid the use of capitalized Request, Response,
and Responder. RFC 2560 is inconsistent in its policy, but generally
uses small letters. The current draft is also inconsistent, although it
tends in the opposite direction.
(4) Sections 4.1 and 4.2 are not about the OCSP request and OCSP
response, as the titles indicate. Instead, they are about the behaviour
of the sender and receiver of the OCSP request, respectively. I suggest
the two sections be entitled:
"4.1 Behaviour of the CERTREQ sender"
"4.2 Behaviour of the CERTREQ receiver"
(5) The second paragraph below the message exchange in section 5.1 is
somewhat mysterious to an outsider. The paragraph begins by saying that
the CERTREQ request could never have happened, even though the message
exchange shows it. I don't understand the final sentence of that
paragraph either. Isn't the OCSP request a set of OCSP Responder
certificate hashes, as defined in section 3.1? If not, the section 3.1
definition should be modified to describe the true contents in this case.
(I'm just guessing that you meant to say that an OCSP request as defined
by RFC 2560 could not be formed by the Responder, and the way around
that is to use the hashed content defined in section 3.1. The final
sentence of section 5.1 hints at this. If that is really what you meant
to say, you'll have to say it a bit more plainly.)
The phrase "(OCSP nonces notwithstanding)" doesn't fit with the
discussion of the issue in the Security Considerations section. Perhaps
you meant to say: "(provided that OCSP nonces are not used)". Following
this sentence, you should add a pointer to the Security Considerations
section, since that sheds considerable light on the situation.
Hope these comments are helpful.
Tom Taylor
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
