Draft:  draft-ietf-pkix-lightweight-ocsp-profile-09
Reviewer: Lucy Lynch [llynch@civil-tongue.net]
Review Date: 4/17/2007
IETF LC Date: 6/29/2006 (-05 reviewed by Ron Bonica)
IESG Telechat Date: 4/19/2007

Summary: This draft is basically ready for publication, but has nits that should be fixed before publication.

Nits Outstanding:

** Obsolete normative reference: RFC 2246 (ref. 'TLS')
    (Obsoleted by RFC 4346)
** Obsolete normative reference: RFC 3546 (ref. 'TLSEXT')
    (Obsoleted by RFC 4366)

There is a direct reference to "3.6. Certificate Status Request" 
in RFC 3546 inline in the text but a diff on sec 3.6 in 3546 vs 4366 shows 
only a few changes in punctuation and line breaks (see attached). Is there 
a reason why these Refs have not been updated?

History:

The last substantive discussions of this draft on the WG list happened in 
2004.

A Last Call Notice was posted Thu, 15 Jun 2006 (v.05) and Ron Bonica 
reviewed the document at that time: 
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-pkix-lightweight-ocsp-profile-05-bonica.txt 
At that time the document was tagged as Informational. The document moved 
to "Proposed Standard" with v.07.

There have been several DISCUSS tokens set on this document and the 
tracker doesn't show the final resolution but given that Sam and Russ are 
still sitting, I'll assume that their concerns have been addressed. I note 
that David Kessens flagged the use of SHA1 as a requirement in a comment 
and I'm guessing that a change in that requirement would require an 
amendment to the current document if it advances to standard.

Review Comments:

One small area of confusion. Is there a potential for a gap in timely 
update given both a "tolerance period" (sec 3) and "using the 
cache-control:max-age directive (sec 5.1) in time-based calculations ??? 
Sorry if I'm being dense here.

Revision Only Comments:

If/when the document gets another revision, two small changes in sec. 
1.2.1 OCSPResponse Structure

   "In the case a responder does not have the ability to respond"
               ^ where

and

   "case a responder only"
        ^ where


===============================================================================

Draft:  draft-ietf-pkix-lightweight-ocsp-profile-05
Reviewer: Ron Bonica [rbonica@juniper.net]
Review Date: Wednesday 7/5/2006 1:23 PM CST
IETF LC Date: 6/29/2006

Summary: This document is almost ready for publication as an
Informational RFC. However, I do have a few small questions, listed below:

1: Something about the formatting of this document caused the IETF ID
Nit-checker to go off the deep end. It detects the following problems
when many of them do not exist.

idnits 1.103

tmp/draft-ietf-pkix-lightweight-ocsp-profile-05.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  * The document seems to lack a Security Considerations section.
  * The document seems to lack an IANA Considerations section.
  * The document seems to lack an Authors' Addresses Section.

    Checking conformance with RFC 3978/3979 boilerplate...

    the boilerplate looks good.

  * There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
    document.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
    Nothing found here (but these checks do not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:
    None.

  Experimental warnings:
  - Missing Reference: 'OCSP' is mentioned on line 616, but not defined
  - Missing Reference: 'OCSPMP' is mentioned on line 634, but not defined
  - Missing Reference: 'RFC2119' is mentioned on line 613, but not defined
  - Missing Reference: 'PKIX' is mentioned on line 621, but not defined
  - Missing Reference: 'HTTP' is mentioned on line 609, but not defined
  - Missing Reference: 'TLS' is mentioned on line 626, but not defined
  - Missing Reference: 'TLSEXT' is mentioned on line 629, but not defined
  - Missing Reference: '0' is mentioned on line 757, but not defined
  - Missing Reference: '1' is mentioned on line 688, but not defined
  - Missing Reference: '3' is mentioned on line 841, but not defined

    Run idnits with the --verbose option for more detailed information.

2: In section 1.1.1 you mandate the use of SHA1. Why SHA-1? Are you sure
that it will be strong enough in the future?

3: In Section 5, you say that clients MUST cache responses? Should that
be a MUST? Why? What would happen if the client didn't cache responses.