Draft:  draft-myers-ikev2-ocsp-03.txt
Reviewer: Tom Taylor
Review Date: Wednesday 7/19/2006 3:40 PM CST
IETF LC Date: 08 Aug 2006

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.