Subject: [Gen-art] Genart review for draft-ietf-pkix-lightweight-ocsp-profile-05

From: Ron Bonica <[email-masked]>
Date: Wed, 05 Jul 2006 14:23:16 -0400

I am the assigned Gen-ART reviewer for this draft, currently on an IESG
telechat agenda. 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 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.

                                    Ron

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Ron Bonica <[email-masked]>
Date: Wed, 12 Jul 2006 10:30:29 -0400

OK. I guess you have addressed all of my comments.

                 -r

Deacon, Alex wrote:
> Hi,
> 
> Thanks for your comments.  My responses are included inline.  
> 
> 
>>-----Original Message-----
>>From: Ron Bonica [mailto:[email-masked]] 
>>Sent: Wednesday, July 05, 2006 11:23 AM
>>To: Deacon, Alex; [email-masked]
>>Subject: Genart review for draft-ietf-pkix-lightweight-ocsp-profile-05
>>
>>  Checking nits according to 
>>http://www.ietf.org/ietf/1id-guidelines.txt:
> I noticed that idnits was reporting false positives.  I'll take a close
> look and see if I can get these errors to disappear.  Its not clear to
> me that its necessary.  
> 
> 
> This only restricts the hash alg used in the CertID structure.  SHA-1 is
> strong enough as the only intent here is to uniquely identify a single
> certificate.  
> 
> 
> Responses must be cached to ensure the load on the infrastructure is
> kept to a minimum and to lessen the number of times a client "hit the
> wire".  The latter being particularly important for constrained clients
> in low bandwidth high latency networks.   This requirement has been
> discussed several times on and off the list and the consensus (IMO) was
> that MUST is what is necessary here.  
> 
> Regards,
> Alex
> 
> 
>>                                    Ron
>>
>>
>>
>>
>>
> 
>