OK with me. Michael Myers wrote:
Tom,Thank you very much for your review. Please advise if actions proposed below are fully responsive to your concerns. Mike (1) Point taken. Will amend the abstract to read: "Certificate Revocation Lists (CRL)" and "Online Certificate Status Protocol (OCSP)". (2) I prefer the current text. I especially do not want to touch the applicability statement as that was hammered out via a conference call and authored by Russ. No change. (2a) You forgot to change your numbering, hence (2a). It had not occurred to me to apply the terminology section in such a fashion. I nonetheless do take your point in that non-experts in this area may become confused when reading RFC2560 in parallel. We will define the terms you cite and normalize usage of those terms throughout the draft. (3) I agree the capitalization practice in the I-D is not useful and potentially confusing. We will amend the draft accordingly. (4) I agree the section titles "OCSP Request" and "OCSP Response" may confuse the casual reader, I prefer however the following: 4.1 Request for OCSP Support 4.2 Response to OCSP Request We will amend the draft accordingly. (5) Point taken regarding the motiviation of the hash approach. Your parenthetical comment is indeed the editorial intent. We will amend the draft to state the issue more plainly. (6) I agree that your proposed text regarding the OCSP nonce caveat improves the text. We will amend the draft accordingly. -----Original Message----- From: Tom-PT Taylor [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 19, 2006 12:40 PM To: Michael Myers; Hannes Tschofenig; Russ Housley; [email protected] Subject: Gen-ART review of draft-myers-ikev2-ocsp-03.txt 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
